|>You don't address protocol negotiation, though, which
|>I think will be necessary: existing servers would interpret
|>the above multi-object request as a single request for '/path/', and
|>new clients wouldn't have any way to tell that what they got back
|>isn't what they asked for. (Checking for 'Content-Type: multipart/xxx'
|>in the reply won't work, since that's a legitimate HTTP/1.0 reply.)
|>
|>Why not call the method 'MGET' and the protocol 'HTTP/1.1'?
OK, sounds fair enough. I would like to increment the protocol minor as well.
This then fits in quite neatly since the server can send a header back
saying the MGET works and the client can remember that for making the inline
requests. so the sequence is :-
GET /fred/page.html http/1.1
If methods is: GET, MGET ...
MGET /fred/ http/1.1
If methods is: GET or response is http/1.0
GET /fred/a
GET /fred/b
..
|>One other question: how does the client tell which body
|>part in the response corresponds to which request?
There have to be headers in each mime segment to specify this.
This is the bit that has not yet been thought out on the multipart front.
OH, before I forget, another good use for the multipart stuff. The message
digest can be sent in the trailer of the message. This means that it is not
necessary to read the file twice, once to calculate the id and again to
send it. The digest can be seeded using a random seed sent encrypted in the
header to avoid multiple RSA processing.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.