What's New:
1) A server keeps the connection to the client live after a transaction
(e.g., GET).
2) A client sends a QUIT command (like FTP clients) when it wants to
close a connection. Otherwise it keeps its connection to the server
open at the end of a transaction.
How it's used:
A client explicitly closes a connection by sending QUIT to the server.
Thus, a client that gets a WWW page can scan it for IMGs and issue new
GETs on the original connection, assuming the IMGs come from the same
server. (Otherwise, the client closes the connection and opens a new
one to the host with the IMG.) When the client finishes the page and
finds no more IMGs, it sends a QUIT, then closes the connection.
Compatibility:
Conversations between QUIT-capable clients and servers follow the
protocol above and (presumably) work more efficiently. Conversations
between non-QUIT-capable clients and servers do what they do now.
When a QUIT-capable client talks to a non-QUIT capable server, it will
experience an unexpected close of the connection -- what the server does
now. It will simply know to create a new connection if it needs further
information from that server.
When a non-QUIT-capable client talks to a QUIT-capable server, the
server will experience an unexpected close while it awaits a command.
The server treats that like an implicit QUIT. The server times out if
it fails to get a new command "soon enough".
I believe this proposal is straightforward to implement in both clients
and servers. Because QUIT- and non-QUIT-capable clients and servers can
interoperate, clients and servers can be upgraded as quickly as practical
once folks agree this is worth doing.
David M. Kristol
AT&T Bell Laboratories