W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

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

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Tue, 18 Nov 1997 13:25:58 -0800
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9711181339.aa15092@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4714
>The Accept-Transfer request-header field is similar to Accept-Encoding, but
>restricts the transfer-codings (section 3.6) that are acceptable in the
>       Accept-Transfer  = "Accept-Transfer" ":"
>                           1#( t-codings [ ";" "q" "=" qvalue ] )
>       t-codings        = transfer-codings
>Examples of its use are:
>       Accept-Transfer: deflate
>       Accept-Transfer:
>       Accept-Transfer: chunk=1.0; deflate=0.5
>The Accept-Transfer header field only applies to the immediate connection.
>Therefore, the accept-transfer keyword MUST be supplied within a Connection
>header field (section 14.10) whenever Accept-Transfer is present in an
>HTTP/1.1 message.

I think this is too verbose (on the wire) and tries to pack in a bunch
of unneeded features.

Qvalues are not useful for transfer encodings -- the coding must not
be lossy, and the vast portion of work is being performed on the server
side, so the server should be capable of choosing which one is best.
Likewise, chunked and identity are always required -- there is no
reasonable use for refusal based on lack-of-encoding.  Thus, the only
feature we actually need is the ability to request a given
transfer-encoding be used.

For that purpose, I suggest we just introduce a Connection keyword
for each new transfer coding.  In other words, an HTTP/1.1 request

    Connection: deflate

indicates the client is willing and able to handle chunked and deflate
(and none) transfer codings on the response.  This is much shorter and
easier to parse than

    Connection: Accept-Transfer
    Accept-Transfer: deflate

Note that we must also include a requirement that chunked be the
last encoding applied if there is more than one.  Note also that this
can be sent in responses as well to indicate the acceptance of deflated
request bodies on future requests, though this would only be useful for
things like printers and WebDAV.

Received on Tuesday, 18 November 1997 14:25:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC