- From: Roy Fielding <fielding@beach.w3.org>
- Date: Mon, 24 Jul 1995 21:58:35 -0400
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Although I strongly favor the use of ASCII encodings of "packet"
>lengths (perhaps we could use a term besides "packet", which will
>cause untold confusion for years to come), I agree that it might
>be nice to use an encoding that occupies a fixed number of bytes.
We could call it "chunky" if you like... I prefer that over "chunks",
though I'm sure we could have no end of amusement talking about
blowing chunks across the network. ;-)
>Note also that if we use a simple ASCII encoding, you need
>to parse the input stream to figure out where the end of
>the "packet" length string is. If we use an encoding that
>takes a fixed number of columns, then you don't need to parse
>anything, you just grab a bunch of bytes.
Good point -- I prefer that as well (in fact, knowing the size of
the size ahead of time was one of the main reasons to do a 256chunk).
>Since I also don't see any reason to limit the "packet" size
>to just 256 bytes, or to any small value, I recommend that the
>length field be fairly large. For example, suppose that the
>standard says "use 6 digits + CR + LF". Then this leaves
>the following data nicely aligned (even for 64-bit machines),
>and allows almost a million bytes per "packet". Better yet,
>use a hexadecimal encoding; this allows >16 million bytes, and
>is much easier to encode and decode.
Hmmm, fixed hex sounds reasonable, but 6 digits is a bit overboard.
And why would we need the CRLF if the size is fixed? It does not
improve readability (aside from the first chunk).
How about four hex bytes:
0 0 0 8
eight bytes of data
F F F F
65,535 bytes of data
0 0 0 0 CR LF
<footer>
CR LF
I would still prefer to see some hard data on the performance
differences. Unlike the rest of HTTP/1.1, this has to be right
the first time its distributed in beta code.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
Visiting Scholar, MIT/LCS + World-Wide Web Consortium
(fielding@w3.org) (fielding@ics.uci.edu)
Received on Monday, 24 July 1995 19:07:59 UTC