httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: Compression via content negotiation
Date Wed, 02 Dec 1998 03:13:56 GMT
On Tue, 1 Dec 1998, Rodent of Unusual Size wrote:

> TE is 'transfer-encoding,' BTW.

No it's not... TE is a silly/confusing name for a new header.  See
draft-ietf-http-v11-spec-rev-xx for whatever xx they're up to these days.

Dean

Here's an older version:

  14.39 TE

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

         TE           = "TE" ":" #( t-codings )
         t-codings   = "chunked" | ( transfer-extension [ accept-params ]
  )
  Examples of its use are:

         TE: deflate
         TE:
         TE: chunked, deflate;q=0.5
  The TE header field only applies to the immediate connection. Therefore,
  the keyword MUST be supplied within a Connection header field (section
  14.10) whenever TE is present in an HTTP/1.1 message.

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

    1. If the transfer-coding is one of the transfer-codings listed in the
       TE 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 TE field includes "identity;q=0".
       The "chunked" transfer-coding is always acceptable. The Trailer
       header field (section 14.40) can be used to indicate the set of
       header fields included in the trailer.

    4.    If the TE field-value is empty, only the "identity" and the
       "chunked" transfer-codings are acceptable.

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

  If no TE 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 header fields other than Content-MD5 and Authentication-Info
  unless the "chunked" transfer-coding is present in the request as an
  accepted transfer-coding in the TE field.

  Fielding, et al                                              [Page 119]^

  INTERNET-DRAFT                HTTP/1.1           Friday,  March 13, 1998

    Note: Because of backwards compatibility considerations with RFC
    2068, neither parameter or accept-params can be used with the
    "chunked" transfer-coding.



Mime
View raw message