Re: HTTP Working Group 'issues' list

Ted Hardie writes:

> I have already seen complaints about Netscape's current behavior on
> several lists, including statements which implied webmasters might
> turn off persistent connections in the face of what they saw as
> "piggish" behavior.  If there is a valid reason for holding open the
> multiple connections, we should probably make it public as soon as
> practicable, or we may find that false beliefs about its interaction
> with multiple connections will slow the spread of persistent connections.

As it stands now the perceived time to render will in many cases go up if 
using a single persistent connection as it takes longer before the required 
metainformation for laying out the page has been transferred. By opening many 
connections you will in most cases get the needed metainformation in the very 
first packets of each connection and to the user this looks like that this 
transfer "mode" is more efficient.

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:

A) Have the server collect metainformation about inlined images and send that 
with the first response which contains the "base" HTML document. This way, the 
page can be layed out as soon as the base document arrives as all information 
about image sizes etc. is known.

This requires that the server parses the base document and knows about the 
various data formats for inlined data objects, for example image/gif. This may 
be an expensive operation but on the other hand, it can easily be cached or 
stored along with the base document, so that it doesn't have to be done every 
time. The information could be included in the response as a new header, and 
if the client does not understand it, it will just be ignored.

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

This does not require that the server knows about the various data formats as 
it can just start sending data on different logical connections as soon as it 
is available. In a simple implementation the SCP doesn't have to allow for 
prioritizing the various logical connections, but in a more general case this 
would be required.

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.

One downside of SCP is that not all data formats have the metainformation in 
the start of teh file but rather in the end. However, I do not recommend that 
this is to taken as a serious problem.

Anyway, these are just some thoughts - I'm sure that the persistent connection 
sub group has considered this in more details?

-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Wednesday, 14 February 1996 14:27:57 UTC