httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: ETag and Content-Encoding
Date Wed, 03 Oct 2007 22:14:57 GMT
Henrik Nordstrom wrote:
> On ons, 2007-10-03 at 13:29 -0700, Justin Erenkrantz wrote:
> 
>> The issue here is that mod_dav_svn generates an ETag (based off rev
>> num and path) and that ETag can be later used to check for conditional
>> requests.  But, if mod_deflate always strips a 'special' tag from the
>> ETag (per Henrik),
> 
> That was only a suggestion on how you may work around your somewhat
> limited conditional processing capabilities wrt filters like
> mod_deflate, but I think it's probably the cleanest approach considering
> the requirements of If-Match and modifying methods (PUT, DELETE,
> PROPATCH etc). In that construct the tag added to the ETag by
> mod_deflate (or another entity transforming filter) needs to be
> sufficiently unique that it is not likely to be seen in the original
> ETag value.
> ...

Two cents -- no three cents :-):

#1) I agree with Henrik's analysis.

#2) If Content-Encoding is implemented through a separate module, it 
will have to rewrite both outgoing and incoming etags; note that this 
includes the "If-*" headers from RFC2616 and the "If" header defined in 
RFC4918 (obsoleting RFC2518).

#3) If just appending "-gzip" doesn't provide sufficient uniqueness, the 
  implementation may want to *always* append a token (such as 
"-identity"), even when no compression occurred.

Best regards, Julian



Mime
View raw message