Re: holding connections open: a modest proposal

Mike Meyer (
Fri, 16 Sep 94 11:03:11 PST

> Why don't you develop the segment idea into a MIME Content-encoding
> type, e.g. Content-encoding: x-stream

This is semantically identical to the "Pragma: keep-alive" idea, with
the addition of tacking a content-length onto the pragma. It's an
improvement because it looks like MIME.

> Rather than a binary value for the segment length, I think we need
> an ascii representation to avoid big-endian/little-endian problems.
> I propose the number is represented as a string of one or more
> digits from '0' to '9' terminated with a '\0' character. This is
> followed by the corresponding number of octets (bytes).

If you're going to MIMEify it, then do it all as MIME:

Content-Encoding: x-stream; length=<digits>

with a newline (or a semicolon) to terminate the length.

> This could then be combined with the keep connection pragma. One issue
> to be resolved would be how x-stream would interact with say x-compress
> or x-gzip. Perhaps we could allow multiple Content-encoding headers where
> the receiving process applies the corresponding decode operation in the
> order the Content-encoding headers appear in the MIME header.

I suggest you look through the MIME archives. This kind of things was
rejected there for good reason. If you need this, send a MULTIPART
mime document with one part. The container has Content-type: x-stream,
the contained part gets Content-Type: x-gzip or whatever.

Clearly, the next version of HTTP needs real protocol negotiation.
Something like the telnet DO/DON't WILL/WON'T protocols, so that
adding minor new capabilities can happen without having to rev the
protocol number.