Re: the eCAP gzip module

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
Received on Thu Jan 29 2009 - 23:10:31 MST