[5634] in www-talk@info.cern.ch
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