Re: holding connections open: a modest proposal

HALLAM-BAKER Phillip (hallam@dxal18.cern.ch)
Sat, 17 Sep 1994 12:24:46 +0200


In article <870B@cernvm.cern.ch> you write:

|>The binary-segmented encoding addresses cases where
|>the server doesn't know in advance how large the
|>object is. It lets the server send data one chunk
|>at a time instead of having to buffer the whole thing.

OK that will do for `functional requirements'

|>[It might also be used to allow clients to prematurely
|>terminate transmission of an object without shutting
|>down the entire session, but I don't know if that's
|>really an issue.]

|>----
|>
|>To summarize: In order to implement an MGET
|>method, or to keep HTTP connections open for multiple
|>requests, there must be an in-band mechanism to delimit
|>the end of a transmitted object. Some options:
|>
|>1. Use multipart/* and BASE64 encoding.
|>2. Use multipart/* and BINARY encoding, and
|> send an accurate content length in the header.
|>3. Use multipart/* and a new, binary, self-delimiting encoding.
|>4. Throw out MIME altogether and use ASN.1 over BER or PER.
|>5. Throw out MIME altogether and use something totally new.
|>
|>(1) is believed to be expensive in terms of CPU and network
|> transmission time.

It would also make Tim B-L very very unhappi. The whole point of HTTP is
to exploit being 8 bit clean. We do not want the smallest toehold for the
people who would start running 7 bit only transports.

|>(2) requires that the server know the content length before
|> it begins transmitting.
|>(3) has not been invented yet.
|>(4) adds a lot of extra complexity for very little payoff.
|> (Before I get flamed for this: ASN.1 is great for complex
|> data structures, but the data on the web just isn't that
|> complex. MIME content-types have been sufficient so far,
|> and probably will be in the future.)

ASN.1 has a different place, for sending raw data arroung for later analysis.
But there are some bits that look usefull.

|>I'm in favor of (3).

Seconded.

How about a compromise on the length. We start out with a four byte length
field BUT we reserve one whole byte of it. Then we can add in session
m'larkey at a later date in any manner we chose. :-

Byte 0: Tag byte

Case byte 0 is 0:
Byte 1: B1 MSB
Byte 2: B2
Byte 3: B3 LSB
< B1 * 256^2 + B2 * 256 + B3 Bytes>

Case byte 0 is not 0
Byte 1: Stream id } Semantics defined by byte 0
Byte 2: Stream id }
Byte 3: Length of header block

Byte 4:
Byte 5:
Byte 6:
Byte 7:
< B3 Bytes of header >
< B4 * 256 ^3 + B5 * 256^2 + B6 * 256 + B7 Bytes>

The semantics of the B1 and B2 fields would be determined by context. For
most cases B3 would be 0 and there would be no `object header'. 16 bits
for a stream tag sounds OK. There can be up to 255 stream modes, the
streams may have data object attachments and there isn't a base 64
encoding anywhere.

I would propose that an area of the byte 0 field be reserved for development
and an area be allowed for experimental use 0 to 191 reserved OK?

BTW on the subject of Base 64 am I in any danger if I include <STDlib.h>
in my programs?

--
Phillip M. Hallam-Baker

Not Speaking for anyone else.