- 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