Re: Holding connections open: an immodest proposal

John Ludeman (
Fri, 16 Sep 1994 00:09:08 +0200

| From: <>
| 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.