Re: Multiple objects in a single transaction: Making it more concrete

hallam@dxal18.cern.ch (HALLAM-BAKER Phillip)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 13 Apr 1994 04:49:46 --100
Message-id: <9404122016.AA06649@dxal18.cern.ch>
Errors-To: listmaster@www0.cern.ch
Reply-To: hallam@dxal18.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: hallam@dxal18.cern.ch (HALLAM-BAKER Phillip)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Multiple objects in a single transaction: Making it more concrete
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1711
In article <6634@cernvm.cern.ch> you write:

|>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-Baker

Not Speaking for anyone else.