Multiple objects in a single transaction: Making it more concrete

Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Date: Sun, 10 Apr 1994 06:13:18 --100
Message-id: <27386.765951010@moose.cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Multiple objects in a single transaction:  Making it more concrete
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2212
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 ]


--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  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here