httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Eckert <thomas.r.w.eck...@gmail.com>
Subject Re: Revisiting: xml2enc, mod_proxy_html and content compression
Date Tue, 14 Jan 2014 13:08:37 GMT
> IIRC the OP wants to decompress such contents and run them
> through mod_proxy_html.  I don't think that works with any sane
> setup: running non-HTML content-types through proxy_html
> will always be an at-your-own-risk hack.

What I want is a (preferrably as simple as possible) method of configuring
mod_proxy_html in such a way that it will attempt to rewrite html(/css/js)
content even if the content was delivered in a compressed format by the
backend server. In my opinion the part about compression should actually be
done transparently (to the user) by mod_proxy_html/mod_deflate.

The reason I brought the .gz files up as example is because they were
handled sligthly incorrect (unnecessary overhead + unpleasant side effect
on client side).


> Gzip compressed content sometimes gets served with no declared encoding
and a media type of, e.g., “application/x-gzip”. I reckon that's more
common than serving it as
> application/octet-stream or with no Content-Type: declared.

> mod_deflate could use this information to avoid compressing the response,
and without sniffing the content.

Exactly what I'm aiming for. I think that's the way to go here, see '1)' in
my previous reply. In this case we should also make mod_xml2enc bail out
with corresponding log message when it gets to see compressed content, e.g.
either via env variable set by inflate filter or read Content-Type header,
so all of the involved modules act consistently and their log output will
not be misunderstood as errors.


> This more limited approach is already available through configuration, so
maybe the way to handle this is via a change to documentation / default
configuration, rather than code.

In order to make mod_proxy_html work with possibly compressed contents you
cannot simply do a
  ProxyHTMLEnable On
and what I have been using since the last discussion which I mentioned
before is
  SetOutputFilter inflate;xml2enc;proxy-html;deflate
with no other explicit configuration of mod_deflate. I'm aware of
    AddOutputFilterByType DEFLATE text/html text/plain text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/x-javascript
application/javascript application/ecmascript
    AddOutputFilterByType DEFLATE application/rss+xml
but this is not compatible with the above output filter chain (see my
previous reply).

Maybe one is able to disable output compression on already-compressed
content with a smart <If> like block but do we really want this as default
configuration ? Is there ever a case where someone does *NOT* want
mod_proxy_html and friends to handle compression transparently ?



On Sun, Jan 5, 2014 at 2:57 PM, Tim Bannister <isoma@jellybaby.net> wrote:

> On 5 Jan 2014, at 02:21, Nick Kew wrote:
>
> > IIRC the OP wants to decompress such contents and run them through
> mod_proxy_html.  I don't think that works with any sane setup: running
> non-HTML content-types through proxy_html will always be an
> at-your-own-risk hack.
>
> I've believed for a while that the right way to address this is for httpd
> to support gzip Transfer-Encoding which is always hop-by-hop and applies to
> the transfer rather than the entity being transferred. For this scenario,
> it could look like this:
>
> [Client] ⇦ gzip content-encoding ⇦ [transforming reverse proxy] ⇦
> gzip,chunked transfer-encodings ⇦ [origin server]
>
> (I'm assuming that the client doesn't negotiate gzip transfer encoding)
>
>
> Of course, this still won't help with a badly-configured origin server.
>
> --
> Tim Bannister – isoma@jellybaby.net
>
>

Mime
View raw message