Re: gzip support

Thus spake Henrik Nordstrom:
> A semantically nontransparent proxy (again, not related to
> interception) is free to implement mostly any entity recoding into
> other entitites such uncompressed->gzip/deflate, gif->png or whatever
> just as a origin server may.
...
> To get a good understanding of Content-Encoding it is best viewed as
> the server driven content negotiation is is. A server capable of
> providing content in multiple different formats for the same URL may
> select the most suitable among the choices it have based on local
> preferences configured in the server and which types are indicated as
> acceptable by the request.

I disagree here. The gzip, compress, and deflate Content-Encodings
are really Transfer-Encodings in disguise -- unlike Content-Type and
Content-Language, they are not a property of the requested entity.

Is there any functional difference between:

Content-Encoding: gzip
Transfer-Encoding: identity

and:

Content-Encoding: identity
Transfer-Encoding: gzip

I don't see a difference, but you guys know the RFC a lot better than
I do :) I ask specifically because there's (at least) one browser
that requests both gzip C-E and gzip T-E. If they are, in fact,
identical, then most of the RFC's objections to munging the Content-
Encoding are unnecessary.

> In both cases the recoded entity is
> another entity in terms of HTTP and you MUST adjust ETag accordingly
> to separate the different variants from each other and SHOULD
> indicate the HTTP-request depended rules used for determining which
> entity to use via Vary.

Is the ETag supposed to be different if you get a chunked-encoded vs
identity-encoded version of the same file? If not, why should a
gzip-encoded version get a different ETag?

> And no, it is not possible to get all this correct in terms of caching
> until the servers, clients and caches properly support at a minimum
> Vary and most preferable ETag as well. ETag support is still missing
> from Squid, but there exists a patch to Squid-2.5 with at least a
> basic implementation.

If Vary is not needed for Transfer-Encoding correctness, I don't see
it being necessary for Content-Encoding correctness either. Of
course, it's still a good idea :)

> Note: Ranges of a "Content-Encoding: gzip" object is ranges within the
> gzipped content, not within the identity encoded object.

Please clarify in the context of my other email :)

> What can however be fully safely implemented in a HTTP/1.1 proxy
> without too much hassle with HTTP semantics is Transfer-Encoding.
> Transfer-Encoding preserves the same identity of the object, only
> compresses the data (for gzip/deflate transfer encoding) for the
> purpose of transmission. A HTTP/1.1 cache MAY precalculate gzip
> encoded reply bodies to increase performance.

So, you agree the idea would fly if we limited it to Transfer-Encoding
support and ignored the (apparently) functionally identical Content-
Ecoding field?

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking