|>Marc VanHeyningen writes:
|>> The question then becomes one of how the client should express to the
|>> server the idea of doing multiple things at once. Here are some
|>> random thoughts...
|>I believe that the client should do a normal initial request and the server
|>will indicate a willingness to do MGET by returning "Public: MGET". The
|>client then indicates it's willingness by issuing the MGET request and
|>tells the server what reply formats it understands in with standard
|>"Accept:" headers. There should be a well defined default so that
|>all clients and servers can talk to each other but we shouldn't rule
|>out future extensions.
|>
|>It would go something like this:
|>
|>client:
|> GET whatever HTTP/1.0
|> Comment: just a normal request
|>server:
|> HTTP/1.0 200 Document follows
|> Accept: [the request formats we accept]
|> Public: MGET
|>
|> [normal return data for whatever]
|>client (note that "whatever" in this request should probably be the
|>same as the above "whatever" for accounting purposes):
|> 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.
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 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.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.