reporter interface can fail to completely load

[Galen Charlton]

On Debian Stretch and Ubuntu Bionic, the reports administration interface can fail to completely load. This results in problems such as an inability to create new folders or templates.

When this happens, the Apache error log will contain errors like this:

Sep 23 14:43:04 gmc-eg apache2[15245]: [:error] [pid 15245] [client 127.0.0.1:60172] XMLENT XML Parse Error: not well-formed (invalid token) at line 2: parsing /openils/var/web/reports/oils_rpt_editor.xhtml: data \n\t\t\t\t</td>\n\t\t\t</tr>\n\t\t\t<!--\n\t\t\t<tr><td colspan='2'><hr/></td></tr>\n\t\t\t-->\n\t\t\t<!--\n\t\t\t<tr>\n\t\t\t\t<th colspan='2'>Output Options</th...

Opening the reports interface in the web staff client and viewing the frame source of oils_rpt.xhtml also shows that the page is incomplete.

As this does not appear to be an issue in Debian Jessie (which has Apache 2.4.10) and Ubuntu Xenial (Apache 2.14.18)

[Galen Charlton (gmc)]

Targeting all currently-supported Evergreen releases as Debian Stretch support (at least) is advertised for all of them.

[Galen Charlton (gmc)]

A WIP patch is available for testing in the user/gmcharlt/nested_reports_includes branch in the working repository.

As near as I can tell, something subtly changed in how Apache handles filters or filtering of subrequests. Since mod_xmlent maintains a shared XML parser per Apache backend and the oils_rpt* interface uses both mod_include and mod_xmlent, parsing fragments out of order in the course of handling a sub-request generated by mod_include would account for the error seen. However, it's not immediately clear to me why this wasn't an issue before.

[Galen Charlton (gmc)]

I've tracked down the apparent relevent difference between Apache 2.4.10/2.4.18 and 2.4.25: in the later version, an EOS bucket appears in the brigade after oils_rpt_param_editor.xhtml is processed by mod_include and mod_xmlent. The presence of that EOS bucket is interpreted by mod_xmlent as a sig that it should reset the XML parser, thus leading to the parsing error when the next chunk is processed.

[Galen Charlton (gmc)]

Some testing suggests that making mod_xmlent free the XML parser only when it gets an EOS for the main request (as opposed to sub-requests) might do the trick without having to rename nested includes.

[Galen Charlton (gmc)]

I've pushed to working/user/gmcharlt/nested_reports_includes_take2 a branch that fixes mod_xmlent instead of working around the problem:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/nested_reports_includes_take2

[Jason Boyer (jboyer)]

The Take2 branch fixes the issue in what I would agree is the better way to do it. Tested and pushed to rel_3_1...master with only a minor comment change (main -> may)

Thanks Galen!