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

• Mail folder: WWW Talk Apr 94-present
• Next message: HALLAM-BAKER Phillip: "Re: Multipart/mixed for many inline images (was Re: Toward Closure on"
• Previous message: HALLAM-BAKER Phillip: "Re: Multiple objects in a single transaction: Making it more concrete"

Errors-To: listmaster@www0.cern.ch
Date: Wed, 13 Apr 1994 05:48:59 --100
Message-id: <6435.766208754@hound.cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Multipart/mixed for many inline images (was Re: Toward Closure on 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2207

[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]
>|>server:
>|>    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  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here