Re: Holding connections open: an immodest proposal

Joe English (jenglish@crl.com)
Wed, 14 Sep 1994 09:43:05 -0700


hallam@dxal18.cern.ch (HALLAM-BAKER Phillip) wrote:

> GET /path/ http/1.0
> Relative-URI: fred.html
> Relative-URL: jim.html
>
> This allows multiple requests in one GET. Note that only a single response
> is returned, a multipart MIME.

This is the most sensible proposal for multi-request
transactions I've seen. With this scheme, it would
take at most two TCP connections to fetch an HTML document
with all its associated inline graphics, annotations, &c.
Two connections seems reasonable.

You don't address protocol negotiation, though, which
I think will be necessary: existing servers would interpret
the above multi-object request as a single request for '/path/', and
new clients wouldn't have any way to tell that what they got back
isn't what they asked for. (Checking for 'Content-Type: multipart/xxx'
in the reply won't work, since that's a legitimate HTTP/1.0 reply.)

Why not call the method 'MGET' and the protocol 'HTTP/1.1'?

One other question: how does the client tell which body
part in the response corresponds to which request?

>One point:
> BURN PRAGMAS !
> PRAGMAS ? - JUST SAY NO.
>
>Pragma keep alive is NOT acceptable. You are modifying the protocol completely
>and not even using a tag. METHOD /url/ HTTP/2.0 is the only acceptable solution

I concur wholeheartedly.

"Session-oriented" HTTP where the connection stays open
may be useful in the future, but a single-transaction,
multiple-object GET request is easier to do and solves
a lot of problems *today*.

--Joe English

jenglish@crl.com