Hi Nick,
On 11/02/2012 07:25 PM CEST +02:00, Nick Kew wrote:
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!
yes, that's also possible.
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.
No, not exactly this edge case. The backend server sends the response
header Content-Type: text/javascript, i.e. without any information
about the used charset. From what I've seen in GDB, mod_xml2enc seems to
resort to assume that the server sends ISO-8859-1 and without an error
converts that to UTF-8 (even though in fact it seems to be mixed
ISO-8859-1 and UTF-8).
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.
Ok, I too wondered about mod_xml2enc staying active being a bug, but was
not sure. So I only fixed the immediate bug. If you consider this a bug,
I assume the Content-Type check just needs to be unified. In
mod_proxy_html check_filter_init() checks for text/html or
application/xhtml+xml, whereas in mod_xml2enc xml2enc_ffunc() checks
for prefix text/ or xml anywhere in the content type string. This is
not consistent, and causes mod_proxy_html to skip text/javascript (or
text/css) files, while mod_xml2enc takes them.
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.
Yes, the delayed checks also seem necessary for the charset guessing in
case no charset is specified.
But what about making the Content-Type check consistent?
Regards,
Micha
