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

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

Henrik

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

***

Accept-Transfer

The Accept-Transfer request-header field is similar to Accept-Encoding, but
restricts the transfer-codings (section 3.6) that are acceptable in the
response.

       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.

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
acceptable.")

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