Re: Content-Transfer-Encoding "packet"

Roy Fielding <fielding@beach.w3.org> said:

  [...]
  > Also, I've been playing around with various formats and have
  > found that the optimum for most transfers uses a simple one-byte
  > prefix to encode the length of each packet, with a zero byte
  > indicating end-of-packets.
Could you elaborate?  I'd be curious to know the tradeoffs you examined
before choosing this approach.  In particular, was the overhead of an
ASCII packet length (i.e., human readable) so onorous?
  > 
  > So, without further ado, here's the format:
  > 
  > Content-Transfer-Encoding: packet
  > 
  >     Entity-Body = *( packet ) NUL
  >                   footer
  >                   CRLF
  > 
  >     NUL         = <octet 0>
  > 
  >     packet      = packet-size packet-data
  > 
  >     packet-size = <OCTET, excluding octet 0, representing
  >                    the unsigned integer (1-255)>
  > 
  >     packet-data = packet-size(OCTET)
  > 
  >     footer      = *( Entity-Header )
  > 
  > Note that the footer is terminated by an empty line (just like the
  > headers) and is optional.  The semantics of a footer are as if the
  > given Entity-Header fields are part of the message headers.

  [most of un-packetizer algorithm omitted]
  	replace Content-Length value with length.
  > 
  > In other words, the result looks like a normal message, with
  > the Content-Length computed by the unpacketizer.  In actuality,
  > it is often faster to read packet-size + 1 bytes, slurping in
  > the next packet-size as part of the prior packet read.

The proposal looks reasonable to me.  I have these questions:

1) If I understand correctly, there is always at least a blank line
following packetized data (for a null footer Entity-Header).  True?

2) Does the footer applies only for C-T-E "packet", or would it
apply to other (to be specified) C-T-E's?

3) What happens if (yes, it would be bizarre) one of the footers is
Content-Length?  (It looks like it gets overwritten with the one that
the packetizer computes.)

4) Will support for packetization be a required part of HTTP/1.1?

5) How will acceptable packet sizes be negotiated (or specified)?

Dave Kristol

Received on Monday, 24 July 1995 07:44:17 UTC