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

• Mail folder: WWW Talk Apr 94-present
• Next message: Marc VanHeyningen: "Re: Multipart/mixed for many inline images (was Re: Toward Closure on "
• Previous message: Dave Lewis: "TIME CRITICAL: **Tue April 19th** SIGWEB Mtg Anncmt: SF Bay Area"
• Maybe in reply to: Ari Luotonen: "Re: Multiple objects in a single transaction: Making it more concrete"

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.