[5659] in www-talk@info.cern.ch
Re: holding connections open: a modest proposal
daemon@ATHENA.MIT.EDU (Mike Meyer)
Fri Sep 16 18:14:22 1994
Date: Sat, 17 Sep 1994 00:04:43 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: mwm@contessa.phone.net
From: mwm@contessa.phone.net (Mike Meyer)
To: Multiple recipients of list <www-talk@www0.cern.ch>
> 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.
<mike
