W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: Transfer-Encoding:chunked

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
Message-Id: <1205448423.10356.55.camel@HenrikLaptop>

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

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

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

Received on Thursday, 13 March 2008 22:48:19 UTC

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