tor 2009-01-29 klockan 23:27 +0100 skrev Constantin Rack: > (b) Concerning the ETag and If-* headers, I am open to your comments. > How should we deal with them? Simply adding a "GZ" suffix to the ETag, > if available?
Either delete ETag + Content-Location on any transformed entity, or make a uniquely identifiable transform of both headers which you are reasonably sure won't collide with whatever the origin server is doing. Sending out the same ETag and/or Content-Location on both original and transformed entities is highly illegal in HTTP rule book as you say they are fully equal in all aspects including content-encoding (and in case of strong ETag even at binary octet level). I would recommend to start out by deleting Etag + Content-Location, and then look into how to safely add an ETag to transformed entities. Adding back a Content-Location is probably outside any reasonable scope as you then not only need to mess with the variant name space beneath the requested URL (ETag and/or Content-Location) but also the servers URL name space in general as the URL given by Content-Location should also be requestable for retrieving that variant without any negotiation. Note: HTTP isn't really designed for content transforming proxies, and many things gets a little shaky in such environment. gzip/deflate by proxies is really intended to be done as a content-encoding which isn't plagued by any of this (as it's transport hop-by-hop, not entity end-to-end), unfortunately support for that hasn't really been picked up anywhere significant.. Second note: The message body looks fully identical if you compare a "Transfer-Encoding: gzip, chunked" message to a "Content-Encoding: gzip" "Transfer-Encoding: chunked" message in HTTP/1.1. The difference is in headers.. Third node: Transfer-Encoding is only valid within HTTP/1.1 and can not be used in HTTP/1.0. Regards Henrik
