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.
John