- 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
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
transfer-coding.
HTH,
Alex.
--
| 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