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 [email protected] MIME, RIPEM & HTTP spoken here