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

> 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
    http://www.ics.uci.edu/~fielding/

Received on Thursday, 29 August 1996 20:08:19 UTC