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 ]
--sample-boundary
Content-Type: message/http-request
GET /foo/image-4.gif HTTP/1.0
Accept: image/gif
[ and so on ]
--sample-boundary--
**************
END OF REQUEST
The above request would be sent to the server as a single unit. The
server response might look something like the following:
SERVER RESPONSE:
****************
HTTP/1.0 200 Document Follows
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="response-boundary"
[ other assorted headers ]
--response-boundary
Content-Type: message/http-response
HTTP/1.0 200 Document Follows
MIME-Version: 1.0
Content-Type: image/gif
[GIF data goes here]
--response-boundary
Content-Type: message/http-response
HTTP/1.0 205 Cached Document Still Current
[ various headers ]
--response-boundary
Content-Type: message/http-response
HTTP/1.0 301 Permanent Relocation URI follows
Location: http://ftp.ncsa.uiuc.edu/bogus/path/name.gif
[ various headers ]
--response-boundary
Content-Type: message/http-response
HTTP/1.0 401 Unauthorized
[ blah blah ]
--response-boundary--
END OF RESPONSE
The above leaves a lot of details out, but gives the essence of how to
encapsulate multiple transactions together without losing the
flexibility of HTTP's content negotiation, response codes, and the
like.
- Marc
-- Marc VanHeyningen [email protected] MIME, RIPEM & HTTP spoken here