Content-Encoding and Filters

[Nick Kew <ni...@webthing.com>]

PRs 23287 and 42993, and recent discussion here, show up some
issues with handling Content-Encoding.  Specifically regarding
mod_deflate, but also relevant to any other filters that
affect or are affected by Content-Encoding.

The root of the problem is that the handling of Content-Encoding
is scattered over too many places:

(1) mod_proxy gets the response header from the backend
(2) mod_mime sets r->content_encoding instead (PR 42993)
(3) CGI and mod_asis set it with other script headers in
    r->err_headers_out.

Case (1) is fine.

Case (2) requires us to accept content-encoding from more than
one potential place.  But just merging them is wrong: if both
are set, they're in competition, and mod_mime's settings are
quite likely to be inherited from a default.  So I think the
correct fix here is to look at r->content_encoding if and only
if there is no Content-Encoding header.  This should really
be fixed in util_filter, rather than fixing mod_deflate and
then potentially duplicating it in other filters.

Case (3) means we *also* need to look in err_headers_out,
which complicates the issue further.  Which raises the
question: can we merge the tables immediately before passing
data down the filter chain?  As far as the handler is concerned,
it can't divert into an errordocument, because it's already
started sending the response.  So there's no longer a
need for two tables, right?

Outline proposal: we look to simplify the issue for mod_deflate
and other output filters by merging headers at the point
where the first data are passed into the output chain.

Looking to 2.4, any strong reason we shouldn't dispense with
r->content_encoding and let mod_mime & friends set the header?

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: Content-Encoding and Filters

[Nick Kew <ni...@webthing.com>]

On Mon, 6 Aug 2007 14:10:10 -0700
"Roy T. Fielding" <fi...@gbiv.com> wrote:

> On Aug 6, 2007, at 1:10 PM, Nick Kew wrote:
> 
> > PRs 23287 and 42993, and recent discussion here, show up some
> > issues with handling Content-Encoding.  Specifically regarding
> > mod_deflate, but also relevant to any other filters that
> > affect or are affected by Content-Encoding.
> 
> I'll just reiterate that the problem is messing with content-encoding
> in the first place.

Well, the popularity of first mod_gzip and now mod_deflate indicates
a clear demand for it.  And it *should* work cleanly in our
filter architecture.

>	  The filter should primarily be working with
> transfer-encoding.

Transfer-encoding is an altogether different filter.
I don't see the relevance.

>	  It is absurd for a run-time server to dynamically
> encode or decode attributes of the representation.

Why?  A lot of people want compressed data.

>	  Content-encoding
> should only be messed with by content-generators, specifically to
> provide a dynamic mapping of non-encoded variants for gzipped files
> to a *different* URIs than the one that is defined to be
> content-encoded, and a third (base) URI for negotiation.

which would seem to preclude dynamic or proxied contents.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: Content-Encoding and Filters

["Roy T. Fielding" <fi...@gbiv.com>]

On Aug 6, 2007, at 1:10 PM, Nick Kew wrote:

> PRs 23287 and 42993, and recent discussion here, show up some
> issues with handling Content-Encoding.  Specifically regarding
> mod_deflate, but also relevant to any other filters that
> affect or are affected by Content-Encoding.

I'll just reiterate that the problem is messing with content-encoding
in the first place.  The filter should primarily be working with
transfer-encoding.  It is absurd for a run-time server to dynamically
encode or decode attributes of the representation.  Content-encoding
should only be messed with by content-generators, specifically to
provide a dynamic mapping of non-encoded variants for gzipped files
to a *different* URIs than the one that is defined to be
content-encoded, and a third (base) URI for negotiation.

....Roy