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.
<mike