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
