Re: gzip support

On Sunday 15 December 2002 22.06, Stephen Sprunk wrote:

> 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

Yes, they are wastly different in terms of HTTP and how the data is
transferred, who is responsible for the compression, and what is
actually the entity being transferred.

The "Content-Encoding: gzip" is end-to-end information about the
coding of the message entity while the "Transfer-Encoding: gzip,
chunked" (you cannot have gzip alone) is hop-by-hop information about
the transfer encoding of the message body along one single hop of the
request chain.

Comparing the two is like comparing transfer of a compressed file over
a uncompressed link to transfer of a uncompressed file over a
compressed transfer link. In both cases the compression saves you
transfer time, but how it is applied is totally different.

Or to quote the RFC:

   3.6 Transfer Codings

   [...]
   This differs from a content coding in that the transfer-coding is a
   property of the message, not of the original entity.

> 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?

Transfer-Encoding DOES NOT modify the message entity-body, it merely
transforms it into another format for the purpose of transmission.

Two response entities with different Entity-Encoding is by definition
two different entities, just as two entities with different
Content-Language or Content-Type are.

> 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 :)

Vary informs about how the entity variant was selected. It is as
needed for Content-Encoding related rules as it is for Content-Type
or Content-Language.

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

It is very interesting for both Content-Encoding and
Transfer-Encofing, but their scope is slightly different.

Transfer-Encoding: gzip can always be applied when negotiated by the
requestor with no need to worry about entities or semantic
transparency, and is very suitable for proxies as it does not have
any sideeffects except for the compression of transferred data.

Content-Encoding can only be applied in a semantically non-transparent
proxy, and is of very much interest for reverse proxies / surrogate
servers at this time, but as the support for content-encoding is
slightly better in the browsers and proxies than transfer-encoding it
is also of interest in normal proxies until transfer-encoding is
better supported.

Regarding ranges:

How ranges are handled are totally different for the two:

- In case of Transfer-Encoding the ranges is on the original entity
and the resulting 206 message body is then transfer encoded with
compression (and finally chunking to delimit the message).

- In case of Content-Encoding the range is on the compressed entity

Regards
Henrik
Received on Sun Dec 15 2002 - 15:11:56 MST