- From: Jeff de la Beaujardiere <delabeau@iniki.gsfc.nasa.gov>
- Date: Wed, 26 Mar 1997 09:49:19 -0500
- To: jg@zorch.w3.org
- Cc: http-wg@cuckoo.hpl.hp.com
Jim Gettys writes in draft-ietf-http-connection-00.txt: > This discussion also shows that a client should close idle > connections before the server does. Currently in the HTTP standard > there is no way for a server to provide such a "hint" to the client, > and there should be a mechanism. This memo solicits other opinions on > this topic. Because resources on the web are typically document-like units comprising HTML and several inline entities like images and scripts, it would seem useful for the server to send a close-connection hint to the client when the server has transmitted, and received ACKs for, all of the content in the current "page." Presumably the user will spend enough time perusing the document that the benefits of maintaining the connection will have diminished to the point of negligibility. Of course, the client may (indeed, should) delay acting on the hint for 10-60 sec in case the user immediately follows an anchor to another document on the server. A server providing web resources of potentially infinite length (like streaming or pushed content) cannot use the same heuristic to determine when to send a close-connection hint, but the same format for the hint could be used regardless of the means by which the server decides it's time for the client to take a hint. When multiple entities are sent, each is preceded by a server response code like "HTTP/1.1 200 OK." Perhaps a final hint entity with a status reponse like "HTTP/1.1 207 Complete Content" could be sent. The entity body could be empty, but it would be useful to include therein related information such as how long the server plans to keep the connection idle before closing it. > * clients SHOULD close connections before servers when possible. > Currently, HTTP has no "standard" way to indicate idle time > behavior to clients, though we note that the Apache HTTP/1.1 > implementation advertizes this information using the Keep-Alive > header if Keep-Alive is requested. We note, however, that Keep- > Alive is NOT currently part of the HTTP standard, and that the > working group may need to consider providing this "hint" to > clients in the future of the standard by this or other means > not currently specified in this initial draft. Apache's Keep-Alive support defines a maximum number of requests and a maximum time to keep the connection open, but these numbers are arbitrary and may not apply to every document on the server. The KeepAliveTimeout could be sent as part of a hint, but the MaxKeepAliveRequests seems useful only for clients that can't take a hint. --Jeff dLB = J-F Pitot de La Beaujardiere = delabeau@iniki.gsfc.nasa.gov = http://globe2.gsfc.nasa.gov/
Received on Wednesday, 26 March 1997 06:54:01 UTC