HTTP [Was Deploying new versions]

John Franks ([email protected])
Fri, 28 Oct 94 08:49:35 CDT

In article <[email protected]>, Can Connolly writes:
>
> Now let's look at the HTTP version mechanism. It seems explicit enough
> that it should provide interoperability across versions. But let's
> look at real scenarios:
>
> In an HTTP 1.0 server, and request with a version > 1.0 should
> be treated as a 1.0 request, rather than causing an error.
> (The request may cause an error for other reasons than the
> version number, of course.)
>
> Any HTTP requests for versions >= 1.0 must function syntactically
> as HTTP 1.0 requests, since when a client sends a request,
> it can't tell what version of the protocol the server implements.
>
>
> By the way... does the idea of the server gratuitously packing up
> inline images with html files into a mime multipart/mixed body really
> look like a good idea to anybody? What about client-side image
> caching? What about per-image errors?
>
> Doesn't it make more sense to just allow multiple transactions over
> the same connection?

Yes.

I would argue strongly for something very simple here even at the expense
of an extra transaction.

C: GET /foo.html HTTP/2.0
Accept: text/html, text/plain
S: HTTP/2.0 200 it is my pleasure to serve you this document...
Content-Type: text/html

S: sends file <closes connection>

So far its identical to 1.0.

C: MGET /images/bar1.gif /images/bar2.gif /images/bar3.gif HTTP/2.0
Accept: image/gif, image/x-xbm
S: HTTP/2.0 0200 a picture is worth a thousand words...
URI: /images/bar1.gif
Content-Type: image/gif
Content-Transfer-Encoding: packet

4006
... 4006 bytes of image data ...
-1
HTTP/2.0 0200 a picture is worth a thousand words...
URI: /images/bar2.gif
Content-Type: image/gif
Content-Transfer-Encoding: packet

5541
... 5541 bytes of image data ...
-1
HTTP/2.0 0200 a picture is worth a thousand words...
URI: /images/bar3.gif
Content-Type: image/gif
Content-Transfer-Encoding: packet

4306
... 4306 bytes of image data ...
-1
S: <closes connection>

This seems to me to have a number of advantages:

1) Simplicity. Simple to implement for clients and servers.

2) Preserves statelessness of the server (VERY IMPORTANT).

3) After first transaction the client can decide which inline images it
needs/wants and request only them. Thus it works for clients which
don't want images or have them cached.

4) Works fine with a 1.0 client and 2.0 server. The initial request
from client is a 1.0 request and subsequently the three images would
be requested in three 1.0 transactions.

5) Works with a 2.0 client and 1.0 server. The initial 2.0 request is
treated by the server as a 1.0 request. The client gets the response
and sees the server is only 1.0 so it gets the three images in three
1.0 requests.

The only drawback that I see is two transactions are required to get
the html document and all the inline images. This seems a small price
to pay. In fact, I cannot see a clean way to do this in one
transaction.

-- 


John Franks 	Dept of Math. Northwestern University
		[email protected]