|>To elaborate on my previous message, here's a rough sketch of how I
|>think a sample transaction of fetching 4 different items from the same
|>server at once might work. This is all rather rough and lots of
|>details would need to be hashed out, but intended to give the flavor
|>of how things might work.
|>
|>REQUEST SENT TO SERVER:
|>***********************
|>MULTICOMMAND HTTP/1.0
|>MIME-Version: 1.0
|>Accept: multipart/mixed
|>Content-Type: multipart/mixed; boundary="sample-boundary"
|>
|>--sample-boundary
|>Content-Type: message/http-request
|>
|>GET /foo/image-1.gif HTTP/1.0
|>Accept: image/gif
|>[ other various headers ]
|>
|>
|>--sample-boundary
|>Content-Type: message/http-request
|>
|>GET /foo/image-2.gif HTTP/1.0
|>Accept: image/gif
|>If-modified-since: 10-Apr-94 00:00:03 GMT
|>
|>
|>--sample-boundary
|>Content-Type: message/http-request
|>
|>GET /foo/image-3.gif HTTP/1.0
|>Accept: image/gif
|>[ etc etc ]
|>
|
This is not necessary, all that is needed is to tell the other end that
multiple commands are to be sent. Then simply concatenate all the
GET, POST etc messages together.
If every message has a properly declared content-length or other terminator
there is no need to use MIME for this. To me a MIME message only
makes sense in the context of a single message consisting of multiple
parts.
By my reading of MIME each part is allowed to have its own headers, but
NOT its own command.
Also the content boundaries are in practice much less useful than
content length encoding since there is no guarantee that a boundary
does not occur in text and no escape mechanism
-- Phillip M. Hallam-BakerNot Speaking for anyone else.