On Fri, 02 Nov 2012 17:05:41 +0100 Micha Lenk <[email protected]> wrote:
> Hi, > > I just debugged a case where Apache used as reverse proxy filters a > text/javascript file through mod_proxy_html and mod_xml2enc. As > mod_proxy_html sees no business in filtering that file, it removes > itself from the filter chain, but mod_xml2enc still tries to do its job. That looks like a logic bug you've found! It looks like an edge case: one you'll only see when the charset coming from the backend is not supported by libxml2 on your platform, so that mod_xml2enc converts it using apr_iconv. > The attached patch based on httpd-trunk fixes that issue by removing the > Content-Length header entirely. Please review it. I would appreciate it, > if it could get applied to trunk and then backported to the httpd-2.4.x > branch. Your patch fixes the immediate bug (thanks!), but the fact that mod_xml2enc is doing anything at all in the case you describe is a bigger bug. There's no easy solution: mod_proxy_html delays some of the checks until it has a first chunk of data, to allow for cases where an earlier filter (e.g. XSLT) might affect Content-Type. But by that time it's too late to insert or uninsert the xml2enc filter, as that needs to go in front of the proxy_html filter. Maybe the best solution is to check content-type at the point where both filters are first inserted. Make that the default for regular users, and make current behaviour a configuration option. Your patch looks good, too, and can be applied independently. I'll do it if Jim (or someone) doesn't get there first! Thanks, -- Nick Kew
