[6418] in www-talk@info.cern.ch
HTTP [Was Deploying new versions]
daemon@ATHENA.MIT.EDU (John Franks)
Sat Oct 29 05:08:28 1994
Date: Fri, 28 Oct 1994 15:53:29 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: john@math.nwu.edu
From: john@math.nwu.edu (John Franks)
To: Multiple recipients of list <www-talk@www0.cern.ch>
In article <9410272140.AA09690@ulua.hal.com>, 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
john@math.nwu.edu
