httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <>
Subject Re: Wrong etag sent with mod_deflate
Date Sat, 09 Dec 2006 14:52:25 GMT
On 12/9/06, Roy T. Fielding <> wrote:
> The best solution is to not mess with content-encoding at all, which
> gets us out of both this consistency problem and related problems
> with the entity-header fields (content-md5, signatures, etc.).
> That is why transfer encoding was invented in the first place.

We don't live in a world that uses Transfer Encoding for gzip.
Firefox, MSIE, and Opera don't support it.  So, dropping Content
Encoding support in mod_deflate is a non-starter.

> We should have an implementation of deflate as a transfer encoding,
> but it should be configurable independent of the existing filter.
> Some people will want TE specifically to avoid the addition of Vary
> and all the other problems that content-changing filters cause.
> For example, an additional directive option for CE, TE, or "either".

As I said earlier, mod_deflate could respond if TE is sent - there's
no need for a directive here.  And it can sidestep the ETag violation
there.  It's a trivial addition to the current filter of just a few
lines.  And, it gives the one cache in the world that doesn't support
Vary a way out.  So, I feel that this resolves the RFC violation that
Squid sees as long as it sends TE: gzip instead.

> The existing filter needs to modify the ETag field value (and
> any other entity-dependent values that we can think of) or be
> removed as a feature.  Weak etags are not a solution -- being able
> to make range requests of large cached representations requires a
> strong etag, and it really isn't hard to provide one.  It is better
> to not deflate the response at all than to interfere with caching.

As Rudiger's patch shows, removing the ETag or appending junk in
mod_deflate isn't enough - you have to teach ap_meets_conditions() how
to know what it is that it's looking at.  I'm against adding ugly
hacks there that make it only know how to handle "-gzip".
(mod_deflate could in theory very well send "deflate" compression.)
So, any solution within ap_meets_conditions() needs to be generic and
not a one-off just for mod_deflate.

> In any case, I won't accept anyone's votes on this issue until there
> is a patch that can be voted on, and the technical considerations of
> security and correctness take priority over other trade-offs.  RTC.

The patch you have been outlining is straightforward - but ultimately
broken because you haven't sketched a way to handle the
ap_meets_conditions() problem.  I'm merely informing you that I will
veto any approach that breaks conditional GETs with real browsers.  I
couldn't care less what a broken proxy cache does (especially if we
can give it way not to be broken) if it means that mod_deflate no
longer supports browser caches.  -- justin

View raw message