httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <>
Subject Re: [users@httpd] [patch] Apache converts GZIPed data into UTF-8 - 2nd Act
Date Mon, 15 Apr 2019 22:46:03 GMT
On Mon, Apr 15, 2019 at 05:21:27PM +0100, Nick Kew wrote:
! > Oh, nobody has an answer to the issue?
! Well I might have done, but I was out rehearsing and performing Bach,
! not reading your email!

Oh, You're perfectly welcome to do so!

In fact I was just hoping for *any* reply - I didn't have the hope to
actually reach somebody deeply involved. Your reply is highly

! mod_proxy_html knows to remove itself from the chain when it sees non-HTML,
! but mod_xml2enc doesn't.

>From my viewpoint, the problem seemed to be that xml2enc is always
pulled into the process-chain, no matter if one wants it or not, and
the (appearingly) only way to avoid that being to not load the module
(and living with the warnings issued on server start).

! > [xml2enc:debug] [pid 52505] mod_xml2enc.c(176): [client] AH01430:
Content-Type is text/css
! At which point, you want the same reaction from xml2enc as from proxy_html.
! i.e. remove itself and leave your contents untouched.

Not really, but that would be a viable approach in the sense of 

No, I would indeed like to run the xml2enc on all kinds of text
(because that may ease my issue with the always-postponed character
coding cleanup on my 20+ years old machines); I just want it to run
where _I_ want it to run - and definitely not on compressed data.

! > [xml2enc:debug] [pid 52505] mod_xml2enc.c(250): [client] AH01434:
Charset ISO-8859-1 not supported by libxml2; trying apr_xlate
! That looks to me like a problem with your libxml2.
! But that's outside the scope of this discussion.

Hm. Another piece of software I never looked at...

! > Then, depending on which filters are configured, this may or may not
! > happen. It may even be runtime dependent. I tried to put proxy_html
! > into a filter chain to get a more defined behaviour, but this is not
! > possible, it produces a configuration error with FilterProvider, 
! Did you misspell it?  It's proxy-html (hyphen, not underscore).

Now that's a hint! Indeed, I probably missed that one - I tried
with and without underscore, upper and lowercase, but likely
not the hyphen... and I failed to find the place in the source
where that name is declared. (Now, knowing the spelling, it is
easy to find ;))

And indeed! That works like I had hoped for - with
"ProxyHTMLEnable Off" and properly steered from the FilterChain,
so I can suppress it on proably compressed objects. 
But it seems proxy-html does not even invoke xml2enc when called
in the filter chain - so the whole issue vaporizes in beauty. ;)

Nevertheless, the average stupid user (like me) might likely start
with the most simple configuration, and might run into this, and
would have a hard time figuring what is actually wrong; so we should
do something about it, and spare them a night searching.

! > Finally I decided to fix the code, as good as I can. (As stated before, 
! > I have absolutely no idea about this stuff and it's conventions, I just
! > need to make the thing workable.)
! Hmm.  Your fix does the job for you, but shouldn't be necessary.

No, it's just that I didn't get it running discretely from the
filter chain.

! I'm thinking, mod_proxy_html does the right thing removing itself.
! mod_xml2enc should do the same when inserted by mod_proxy_html.

Yepp, and leave the option to insert xml2enc explicitely for other 
kind of files, if one wants to do that! Agreed!

Whereas, in an ideal world, mod_proxy_html would not stand down, but
would fixup the URLs in the stylesheet-documents as well. 
But then, most people are concerned about performance and use an 
asset-server anyway and not get such documents from the backend
(while I am just using Rails as scriptable database-GUI that I can
reach from anywhere in the world, disregarding performance), so
public demand for this may be limited; and it can nicely be done with

! Thanks for the detailed analysis!

Thanks for the (unvoluntary) invitation to look a bit deeper
into the internals of that apache beast. :))


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message