httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: Wrong etag sent with mod_deflate
Date Sun, 10 Dec 2006 09:06:35 GMT

Roy T. Fielding wrote:
> On Dec 9, 2006, at 6:23 AM, Justin Erenkrantz wrote:
>> However, I disagree with Roy in that we most certainly *do* treat the
>> ETag values as opaque - Subversion has its own ETag values - Roy's
>> position only works if you assume the core is assigning the ETag value
>> which has a set format - not a third-party module.  IMO, any valid
>> solution that we deploy must work *independently* of what any module
>> may set ETag to.  It is perfectly valid for a 3rd-party module to
>> include "-gzip" at the end of their ETag.  For example, if you had a
>> file called "foo-gzip" in revision 10, SVN would assign the ETag
>> "10//foo-gzip".  (And, I could construct a conflict where httpd would
>> hork the ETag incorrectly for any arbitrary value.)  -- justin
> No, you assume a broken implementation of ap_meets_conditions.
> If the function is implemented correctly, it still treats each etag
> as opaque.  Given an etag of "X", the deflate variant will be "X-gzip".
> If the content generator generates "10//foo-gzip", then the deflate
> filtered variant will use "10//foo-gzip-gzip".  The result is correct
> and no butt-ugly hacks are needed.  The same can be done for any
> content-changing filter, and the result will work as specified as
> long as the ordering of filters is consistent (and even if it isn't,
> the result remains correct with a slight inefficiency).
IMHO, this fixes the symptom, but not the problem; what happens when 
someone comes up with a model where the compression level can be changed 
(e.g., gzip --fast .. --best)?  In such a case, the content-encoding 
still works (since the decompresser will detect this on its own), but 
the entity will still be different in different cases which turns us 
back to the same "different ETag" problem. 


PS.  Roy, just out of curiosity, since HTTP/1.1 was already a standard 
before I had any involvement with the community, why was there a 
differentiation between Content-Encoding and Transfer-Encoding in 
HTTP/1.1 in the first place?   It seems to me that we wouldn't need to 
deal with these problems if compression was made a property of the 
message, rather than the entity.  (I'm sure the answer is a simple and 
valid one; I'm just asking if you can point me in the correct direction)

View raw message