Re: Multipart/mixed for many inline images (was Re: Toward Closure on

Marc VanHeyningen (
Tue, 12 Apr 1994 22:45:54 -0500

[I hate mailing lists, it's so hard to keep the citations straight...]

Phillip Hallam-Baker said:
>Somebody, I can't remember who and the citation line just said "You", said:
>|>It would go something like this:
>|> [ ... ]
>|> MGET whatever HTTP/1.0
>|> Accept: [the reply formats we accept]
>|> Content-type: multipart/mixed
>|> [the various requests encoded as message/http-request]
>|> HTTP/1.0 200 Document follows
>|> Content-type: multipart/mixed
>|> [the various replys encoded as message/http-reply]
>If you want to get a multipart document then the syntax should be
>GET whatever HTTP/1.0
>Accept: multipart/mixed
>There is no need at all to extend the current specs. The beauty of this
>scheme is that it is not necessary to change any clients or whatever.

This is reasonable; this would be the way to get a multipart document,
and it is an excellent solution to the problem as you describe it.

However, it is not a solution to the problem being discussed, which
was how to permit multiple transactions with a single server to be
handled as a single transaction so as to reduce the overhead of
setting up and tearing down the connection for each transaction.

>A multipart GET only makes sense if the URL refers to a multipart object,
>there is no intrinsic difference between a text only fragment,and a
>combined text, video, audio collection.

The purpose of a multipart GET is to fetch more than one URL at a
time (or, more generally, to POST or HEAD or PUT or whatever method
one likes to various URLs at one time.) Whether each of these URLs
refers to a multipart object is irrelevant.

>The only protocol distinction is when the multipart message is a stream
>of interactive data. In this case we have a series of MIME segments each
>of which must be handled as it arrives. This is the basis for encapsulating
>real time video and audio into the web. An interactive HTTP channel is
>a HyperTerminal connection.

Um, that sounds neat, but it sounds quite a step up from what we have
now. Are there some specs for this or are you just thinking out loud?

- Marc

Marc VanHeyningen  MIME, RIPEM & HTTP spoken here