[5714] in www-talk@info.cern.ch
Re: holding connections open: a modest proposal
daemon@ATHENA.MIT.EDU (Joe English)
Mon Sep 19 16:45:54 1994
Date: Mon, 19 Sep 1994 22:37:29 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: jenglish@crl.com
From: Joe English <jenglish@crl.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
mwm@contessa.phone.net (Mike Meyer) wrote:
> > 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.
>
> In that case, why not use message/partial with a content length on
> each part, and a total on the final part?
OK, I'll buy that.
So an MGET response returning an HTML node, one small
inline image, and one large automatically-generated
GIF could look something like this:
| <example>
| Content-type: multipart/mixed; boundary="outermost"
| Base-URL: http://www.somewhere.com/
|
| --outermost
| Content-Description: main document
| Content-Type: text/html
| Content-Transfer-Encoding: binary
| Content-Length: 1477
| Relative-URL: /foo/bar/maindoc.html
|
| [ HTML document here; uses binary transfer encoding with explicit
| length in case the document contains \n--outermost\n boundary
| string. 'quoted-printable' would also work, or just '8bit'
| if server was willing to check for the boundary string before sending. ]
|
| --outermost
| Content-Description: inline image
| Content-transfer-encoding: binary (illegal in RFC1522, OK in WWW)
| Content-length: 7001
| Content-Type: image/gif
| Relative-URL: /foo/bar/blueball.gif
|
| [exactly 7001 bytes of binary data immediately following the CRLF.]
| --outermost
| Content-Description: generated image
| Content-Type: multipart/mixed (or parallel?); boundary="segment-delim"
| Content-transfer-encoding: 7bit (though subparts use 'binary')
| Comment: this body part is an encapsulated message,
| split up into message/multipart and repackaged as multipart/mixed
| on the fly as the image is generated.
|
| --segment-delim
| Content-Type: message/partial; id=www.somewhere.com:012345; part=1
| Content-transfer-encoding: 7bit
| Comment: first part of the message/partial message is the header
|
| Content-Type: image/gif
| Relative-URL: /cgi-bin/buildpicture.pl/foo/bar
|
| --segment-delim
| Content-Type: message/partial; id=www.somewhere.com:012345; part=2
| Content-transfer-encoding: binary
| Content-Length: 65536
| Comment: first part of actual data
|
| [exactly 65536 bytes of binary data]
| --segment-delim
| Content-Type: message/partial; id=www.somewhere.com:012345; part=3
| Content-transfer-encoding: binary
| Content-Length: 65536
|
| [exactly 65536 bytes of binary data]
| --segment-delim
| Content-Type: message/partial; id=www.somewhere.com:012345; part=4; total=4
| Content-transfer-encoding: binary
| Content-Length: 101
|
| [exactly 101 bytes of binary data]
| --segment-delim--
|
| End of inner multipart/mixed body part
|
| --outermost--
|
| End of MGET response
|
| </example>
Something similar but with one less layer of encapsulation
would be used for multi-request HTTP.
> > 3. Use multipart/* and a new, binary, self-delimiting encoding.
> [...]
> > (3) has not been invented yet.
> No, the mechanism in the current encoding scheme just isn't being used
> yet.
This isn't really a self-delimiting encoding though, since
the content length is in the header; it just uses currently
defined MIME mechanisms to get around the problems with
that approach. (OK, minor nitpick, I know.)
--Joe English
jenglish@crl.com
