RE: Stayin' Alive

John Ludeman (
Tue, 6 Dec 94 10:42:50 TZ

| From: Rick Troth <troth@UA1VM.UA.EDU>
| Subject: Stayin' Alive
| Date: Tuesday, December 06, 1994 4:27PM
| JR said:
| <excerpt>
| The desire to do multiple HEAD transactions is a powerful argument in
| favor of holding off closing this issue. I'm pretty sure I'm going to
| eventually want multiple HEADs, CHECKOUTs, PUTs, and DELETEs, at least.
| ...
| </excerpt>
| Wow. This tells me we really do want a more general "STAY ALIVE"
| or "KEEP CONNECTION" model. I was feeling a little shy about putting
| forth my own suggestion(s), but I've got "running code". All I need
| is that "rough concensus" to meet the Dave Clark Criterion. ;-)

Hi Rick,

The way this has been discussed on www-speed (and subsequently
www-talk) is to add a HTTP header line "Pragma: Keep-connection" that
basically works like:

Client Sends: GET /foo.html HTTP/1.0
Pragma: Keep-connection

If the server supports the pragma and the item being requested has a
known length, it includes the pragma in the reply:

Server Sends: HTTP/1.0 200 OK
Pragma: Keep-connection
Content-length: 2048

The server then optionally keeps the connection open for x
seconds/minutes waiting for the client to make the next request. The
pragma is only used on the first transaction. The server is free to
close the connection at the end of any request, which the client should
accept as the end of data (as happens today).

The only tricky part for the client is a race condition between a
client request and the server closing the connection (due to server
load, timeout etc.). In this case, the client just retries the request
with the TCP session setup.

As you noted, in the cases where the content length is not known such
as from server scripts, a packet approach would be nice. My personal
take is it's not worth it to modify HTTP/1.0 to support packets like
this as that support is already speced for HTTP-NG. Retrieving n files
with known lengths is the most common case (i.e., a homepage with seven
images) and is the most interesting one to optimize especially
considering the trivial changes needed by the client and server.