httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: [PATCH] mod_xml2enc eats end of file
Date Fri, 02 Nov 2012 18:25:13 GMT
On Fri, 02 Nov 2012 17:05:41 +0100
Micha Lenk <micha@lenk.info> 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

Mime
View raw message