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

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

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Mon, 17 Nov 1997 16:53:39 -0500
Message-Id: <>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4701

As I mentioned in a previous mail [1], content-codings and transfer-codings
share a lot of the same sementics but have different scopes. Currently a
client can control the content-encodings sent by a server, but can not
control the transfer-codings. This is the purpose of the Accept-Transfer
header field.

Both Accept-Encoding and Accept-Transfer should have been general header
fields instead of request header fields but it's too late to change now.

I don't think it makes sense to have a "*" as acceptable transfer codings
as the client MUST know the transfer coding in order to find the End of


[1] http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0157.html



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

A server tests whether a transfer-coding is acceptable, according to an
Accept-Transfer field, using these rules:

1. If the transfer-coding is one of the transfer-codings listed in the
Accept-Transfer field, then it is acceptable, unless it is accompanied by a
qvalue of 0.  (As defined in section 3.9, a qvalue of 0 means "not

2. If multiple transfer-codings are acceptable, then the acceptable
transfer-coding with the highest non-zero qvalue is preferred.

3. The "identity" transfer-coding is always acceptable, unless specifically
refused because the Accept-Transfer field includes "identity;q=0", or
because the field includes "*;q=0" and does not explictly include the
"identity" transfer-coding.  If the Accept-Transfer field-value is empty,
then only the "identity" encoding is acceptable.

If an Accept-Transfer field is present in a request, and if a server cannot
send a response which is acceptable according to the Accept-Transfer
header, then the server SHOULD send an error response with the 406 (Not
Acceptable) status code.

If no Accept-Transfer field is present, the sender MAY assume that the
recipient will accept the "identity" and "chunked" transfer-codings. 

A server using chunked transfer-coding in a response MUST NOT use the
trailer for other header fields than Content-MD5 and Authentication-Info
unless the "chunked" transfer-coding is present in the request as an
accepted transfer-coding in the Accept-Transfer field.

Received on Monday, 17 November 1997 13:58:43 UTC

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