Re: Accept-Transfer header field (was HTTP/1.1 Issues:

Roy (humbly) proposed:

    The same thing can be (IMHO) more easily accomplished as

    Connection: deflate
    Deflate: --best

This has some things to recommend it, but unfortunately it
won't quite work.  The most significant problem is that it
doesn't work with multiple transfer-codings on the same message.

I.e., the rules for Transfer-Encoding (as for Content-Encoding)
with multiple codings are quite clear:

	    If multiple encodings have been applied to an entity, the
            transfer codings MUST be listed in the order in which they
            were applied.

E.g.,

   Transfer-Encoding: gzip, twiddle

unambigously means that 
	message-body = twiddle(gzip(entity-body))

and section 4.2 (Message Headers) guarantees that the ordering
of transfer-codings in this header field is reliable.

However, you can't make the same guarantee if each coding
is described by a separate header, since section 4.2 (Message
Headers) says:

	    The order in which header fields with differing field names
            are received is not significant.

We could fiddle with 4.2, or with the definition of Connection,
or add some new optional mechanism for imposing an ordering on
header fields with differing field names.  But these all seem a
lot more disruptive (especially for the installed base) than
simply doing something analogous to Accept-Encoding/Content-Coding.

Koen writes:
    And no gunky parameters about compression quality or dictionaries
    please -- adding these would take the whole thing way beyond a 1.1
    cleanup, and how are we ever going to claim two independent
    implementations for such things if we add them?

Well, Henrik has already promised one (right, Henrik?) and I would
guess that he is right; adding a parameter parser for Accept-TE
is relatively easy if you've already had to right the same parser
for "chunked".

But beyond that, if we don't add parameters NOW, we will never
be able to do so, because then there will be an incompatibility
with the installed base.  History has shown us that HTTP has
suffered in many ways from a lack of extensibility mechanisms,
and since this one is exactly the same as we already have used
in other headers, it seems rational to use it for transfer-codings.

-Jeff

Received on Wednesday, 19 November 1997 14:39:45 UTC