W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: HTTP Working Group 'issues' list

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Wed, 14 Feb 1996 18:55:35 -0800
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9602141855.aa17794@paris.ics.uci.edu>
> I don't think we can sell the concept of persistent connections as being a 
> more "social" behavior but as I see it we have at least two alternatives in 
> order to improve the perceived performance of persistent connections. Please 
> note that I am not talking about absolute performance gains but in what the 
> user actually sees on the screen:

Actually, preliminary tests with Apache would seem to indicate that the
user's perceived performance improves on a keep-alive'd server if the
number of simultaneous connections is set to 2 versus 3 or 4 or 1.
That is in addition to a dramatic decrease in server load.
I think it is due to slow start and the cost of squeezing multiple requests
through a single pipe, but these tests were only preliminary.

> A) Have the server collect metainformation about inlined images and send that 
> with the first response which contains the "base" HTML document....

No way.  Aside from being expensive, the images may not even be on the
same server.  Image size hints belong in the referring document.

> B) Implement a session control layer on top of HTTP along the lines
> that Simon 
> has described in his SCP protocol. You can find a copy of that from
> 
> 	http://www.w3.org/pub/WWW/Protocols/HTTP-NG/http-ng-scp.html

Good idea, but not applicable to HTTP/1.x.  As they say, "build it and
they will come".  It is what I call HTTP/2.0.

BTW, for those of you who are wondering, all different versions of HTTP
are in fact different protocols.  They share the name HTTP only because
they correspond to the protocol expected when communicating directly
with an "http" service.  In order to become HTTP versions, they must
obey the constraints placed on HTTP-Version.  The reason for those
constraints is to prevent changes in the protocol from breaking prior
applications when they encounter an http URL.

Thus, all HTTP/1.x requests are compatible in format with HTTP/1.0,
and any correctly implemented HTTP/1.0 server can understand (though
perhaps with some loss of optional information) an HTTP/1.x request.
Likewise, an HTTP/2.x server is required to understand an HTTP/1.x
request, even though the response may just be "I don't support you."

That has been in the design of HTTP since 1992, though we should add a
specific status code for the "I don't support your protocol version".

> The problem is how to make the transistion from a normal HTTP request to a SCP
> response without loosing a RTT. The Upgrade header would be good for that but 
> the current specification does not allow the swap to happen on the fly. As I 
> can see that in some cases, the 101 response is useful, it may also be a good 
> idea to be able to do it on the fly.

Que?  Whatcha talkin' bout Henrik?  The Upgrade header goes into operation
as soon as the first request is received and the 101 response sent back.
You can't get any more "on the fly" than that without making the first
request invalid.  After the first request, the client knows the protocol
version of the server and can immediately do whatever multiplexing
would be called for by the new protocol from then on.  The only way
to avoid the RTT is to know in advance that the server supports the
higher protocol, in which case Upgrade would not have been used.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/
Received on Wednesday, 14 February 1996 19:37:00 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:45 EDT