[5634] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

Re: Holding connections open: an immodest proposal

daemon@ATHENA.MIT.EDU (John Ludeman)
Thu Sep 15 18:27:25 1994

Date: Fri, 16 Sep 1994 00:16:14 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: johnl@microsoft.com
From: John Ludeman <johnl@microsoft.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>


----------
| From:  <hallam@dxal18.cern.ch>
| When I raised the idea of keeping the connection open for this purpose at
| WWW'94 there was quite a bit of resistance to the idea. It is a small step
| for coding to do something that optimises our current situation. BUT we
| want to be arround in ten years time. Before we allow continuous connection
| into the spec we have to demonstrate that it works through proxies, and
| can provide the conferencing, hyperterminal and transaction processing
| benefits too.

I think people are making too big of an issue with this.  Using Pragma: 
Keep-Connection, the protocol isn't being changed.  The session 
behaviour is optimized but the basic model isn't changed.  I think 
everyone agrees multiple sessions for a single document has got to go.  
Pragma: Keep-connection provides this capability *and works with 
existing servers*.  It works with existing proxies, it works with 
existing clients.

In HTTP/1.1, MGET is good (done in a single session(!)).  But people 
need to understand this is not a minor code change and there will be a 
significant lag before it has wide support.

Multipart opens a really big can of worms on the server especially on a 
server that has thousands of simultaneous requests.  CPU will almost 
assuredly become the bottleneck as the server will have to parse all of 
the HTML docs and generate a composite.  Are we really sure we want to 
sacrifice the server like this?

|
[...]
| >Stuff is coming along that
| >will require negotiation between client and server:  security, and
| >payment for information.
|
| Negotiation is not required for security. In many circumstances a one shot
| connection can be maintained. for more details consult the Shen docs:

Negotiation *is* required for security in some challenge response schemes.

[...]

John

home help back first fref pref prev next nref lref last post