That's what I was proposing.
mwm@contessa.phone.net (Mike Meyer) wrote:
> 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.
In that case, why not just use 'Content-Transfer-Encoding: binary'
and require 'Content-Length:' to be accurate?
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.
[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.
(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.)
I'm in favor of (3).
--Joe English
jenglish@crl.com