- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Thu, 13 Mar 2008 23:47:03 +0100
- To: szukw000@arcor.de
- Cc: ietf-http-wg@w3.org
On Thu, 2008-02-28 at 19:06 +0100, szukw000@arcor.de wrote: > This part of the spec is too laconic. Several questions arise and MUST be answered: > > 1. WHY chunked encoding? To support persistent connections when not knowing the Content-Length. > 2. HOW chunked encoding? Per the definition of "Chunked Transfer Encoding". > 3. WHY chunk-extensions? Future extensibility. > 4. WHICH chunk-extensions? None defined yet. And it's possible there never will be one defined for HTTP. Other users of Chunked Transfer Encoding have defined chunk extensions, for example the ICAP protocol. > 5. WHY trailer? To support things like Content-MD5 which can not be calculated before the whole response is known. > 6. WHICH trailer lines? Defined in RFC2616. See the definitions of "Trailer" and "Chunked Transfer Encoding" which explains how the trailer may be used and what needs to be considered before placing a entity header in the trailer section. > chunk-size: MUST fit a UINT > xor MUST fit a ULONG > or MAY exceed a ULONGLONG and the variable MUST be a FLOAT Specifications do not impose a limit on chunk-size. No more than it does on Content-Length. But implementations are expected to appropriately reject size specifications it can't handle or decode. Regards Henrik
Received on Thursday, 13 March 2008 22:48:19 UTC