tor 2006-12-07 klockan 02:42 +0100 skrev Justin Erenkrantz: > -1 on adding semantic junk to the existing ETag (and keeping it > strong); that's blatantly uncool. Any generated ETag from mod_deflate > should either be the original strong version or a weak version of any > previous etag. mod_deflate by *definition* is just creating a weak > version of the prior entity.
You basically only have two choices: a) Make mod_deflate not send an ETag on modified responses. b) Modify the value (within the quotes) of the ETag somehow. And if mod_deflate can not be trusted to always return the same octet representation make sure to use an weak ETag unless the ETag generation is also tightly coupled to the octet representation guaranteing a different ETag should mod_deflate encode slightly different. And to be fully compliant you also need to pay attention to the Content-Location header. Here I don't see much choice but to not send Content-Location in mod_deflate mangled responses (but can be kept on the original response, no problem there). RFC 2616 13.6 Caching Negotiated Responses, last paragraph. > mod_deflate does properly stick in the Vary header, so caches already > have enough knowledge to know what's going on anyway even without a > fix. (This is probably why mod_cache doesn't flag it as an error.) > My opinion is to fix the protocol and move on... -- justin The protocol is quite fine as it is, and not easy to change. As it is now it's mainly a matter of understanding that mod_deflate does create a completely new entity from the original one. To the protocol it's exactly the same as when using mod_negotiate and having both the identity and gzip encoded entities on disk. The fact that you do this encoding on the fly is of no concern to HTTP. Another option is to explore the use gzip transfer encoding instead of content encodin. In transfer encoding none of these problems apply as it's done on the transport level and not entity level, but it's not that well supported in clients unfortunately.. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
