On 12/9/06, Roy T. Fielding <[EMAIL PROTECTED]> 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
