Re: errata for RFC 2616 & 2617

Patrick McManus <mcmanus@appliedtheory.com> writes:
    ::  Section 3.6 calls for IANA to establish a registry of
    :: "transfer-coding value tokens" that includes
    :: "chunked" and "identity", but goes on to list
    :: "gzip", "compress" and "deflate". But "gzip", "compress"
    :: and "deflate" are not transfer-coding value tokens, they're
    :: content-coding value tokens.
    
    I don't get it.. but, I am having a bad day so it's most likely my
    fault at interpretation.. but I thought the various compression
    codings made sense for both content-coding and transfer-coding..
    
You're right; RFC2616 is pretty clear that there are two distinct
IANA registries, one for content-coding and one for transfer-coding.
Both registries currently contain the subset
	gzip|deflate|compress|identity
but only transfer-coding also includes
	chunked
and only content-coding also includes (as deprecated choices)
	x-gzip|x-compress

    here's my understanding: they are different things: the former is a
    property of the entity, and the latter is a property of the
    message.. and the various proxies and clients in the chain are
    going to handle them differently depending on whether they are
    content or transfer based (i.e. application/postscript that is
    content-coded gzip should probably be saved to disk as .ps.gz but
    if it is transfer-coded gzip then the UA would like decompress and
    display, and if anything gets saved it's the .ps only), but the
    algorithms and encodings themselves make sense in both contexts..
    whereas something like chunked or jeff's delta musings make sense
    only as transfer encodings.

Actually, our "Delta encoding in HTTP" draft
	http://www.ics.uci.edu/pub/ietf/http/draft-mogul-http-delta-01.txt
has a lengthy discussion of this issue, and shows that delta encoding
can be done either way - as a content-coding or as a transfer-coding.
(See section 5.3 of that draft, conveniently titled "Content-coding or
Transfer-coding?".)

There are some tricky interactions between content-codings,
transfer-codings, and range responses, which are explained in section 4
of that draft ("Relationship between content-coding, transfer-coding,
and ranges"), although these are not specific to delta encoding.

Once you take these interactions into account, in fact, delta encoding
usually makes more sense as a content-coding than as a transfer-coding.

In your example of a response that is marked
	Content-type: application/postscript
	Content-Encoding: gzip
it's not entirely clear to me whether it should be saved to
disk in compressed format, but if one wants to actually display
this response in a browser (or a helper application, in this case)
it should certainly be decompressed first.

-Jeff

Received on Tuesday, 27 July 1999 13:08:32 UTC