W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Question on Chunk-Size sect 3.6, 8/12/96

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Thu, 29 Aug 1996 19:56:44 -0700
To: "John C. Mallery" <jcma@ai.mit.edu>
Cc: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <9608291956.aa10242@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1529
> Clever implementations of chunked transfer encoding will do it
> by using the tcp buffer directly, thereby eliminating the need to
> copy to another buffer and reducing the working set.
> This is accomplished by reserving space at the beginning of a chunk for
> the size and any chunk arguments, and then filling them in before transmitting
> the buffer. Most simply, this requires using come padding characters before
> or after the hex chunk size.

When I proposed the chunked encoding to this WG (Dan Connolly originally
suggested it on www-talk more than a year before that), I wanted a fixed
chunk size (and no CRLF's) for the same reason.

> However, at first blush, the spec seems cleverly engineered to prevent 
> using any padding, front or back. 
> BUT, in section 2.1 where implied *LWS is discussed, it suggests that
> whitespace may appear between  and delimiters without changing the interpretation of a field.
> Thus, hex-no-zero *lws CRLF would be legal. 

Ummm, no, that would be bad because LWS may include CRLF.  Under
the circumstances, the spec could say

       chunk          = chunk-size [ chunk-ext ] *(SP | HT) CRLF
                        chunk-data CRLF

and explicitly disallow any other LWS between chunk-size and chunk-data CRLF
(as it does for the other cases where CRLF is acting as a delimiter).

> Does this mean that padding the chunk-sized with spaces on the right is
> legal in the current http 1.1 spec?

Well, it isn't illegal, but that won't help interoperability any.

> If so, section 3.6 should be updated to make this clear.
> If not, section 3.6 should be amended to correct this mistake.

*sigh*, I hope someone is making a list of these.

> All the known 1.1 clients that have tested against the server (2 W3C clients
> and one from Switzerland) have been able to deal fine with trailing
> whitespace before a ";" or the CRLF

That's how I'd implement it as well, just for the sake of robustness.

> I think this mistake should be corrected as quickly as possible.

Not possible without issuing another draft.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Thursday, 29 August 1996 20:08:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:18 UTC