W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2002

Re: Chunking requirement

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Fri, 25 Oct 2002 09:15:27 -0600 (MDT)
To: Diwakar Shetty <Diwakar.Shetty@oracle.com>
cc: ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.44.0210250848460.58381-100000@measurement-factory.com>

On Fri, 25 Oct 2002, Diwakar Shetty wrote:

> Is it a "MUST" requirement for HTTP/1.1 clients to support chunking ??

Yes, it is. RFC 2616 says:

   All HTTP/1.1 applications MUST be able to receive and decode the
   "chunked" transfer-coding, and MUST ignore chunk-extension
   extensions they do not understand.

Support for the above MUSTs varies, and there are known buffer overrun
bugs in some older versions of popular clients and servers. Many
_servers_ have quite poor support for chunked _requests_, but you
probably do not care about that.

> Or Is the chunking capability to be advertised by the client before
> the server can send chunked encoded response?

The only required "advertisement" is "HTTP/1.1" request version.
Clients MAY include TE request-header to indicate that it supports
[other] transfer-codings and/or trailers. However, the "chunked"
transfer-coding is always acceptable, regardless of TE header presence
and value. Some clients send "TE: chunked" anyway. Some HTTP/1.0
clients send "TE: chunked" to indicate that they can accept chunks
despite being HTTP/1.0.

The client should advertise its "trailers" capability though:

   The presence of the keyword "trailers" indicates that the client is
   willing to accept trailer fields in a chunked transfer-coding, as
   defined in section 3.6.1. This keyword is reserved for use with
   transfer-coding values even though it does not itself represent a



                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance
Received on Friday, 25 October 2002 11:15:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:36 UTC