- From: Roy T. Fielding <fielding@ebuilt.com>
- Date: Fri, 16 Mar 2001 17:33:55 -0800
- To: Miles Sabin <MSabin@interx.com>
- Cc: http-wg@cuckoo.hpl.hp.com
"Server receives a FIN" and "HTTP connection is closed" are two different things. The first is one part of a TCP handshake for which HTTP has no business defining the rules (HTTP is transport independent), and the second is something that an application has to find out from whatever network API it is using for sending/receiving HTTP bytes. Using the typical socket API with TCP, an HTTP connection is considered to be closed when it receives a fatal error or EOF either: 1) when attempting to read an unfinished request and there are no pending responses being sent on the connection (this is easily determined because all HTTP requests are length-delimited), or 2) when writing a response. Note that the above applies to the socket API. There may be a completely different algorithm for determining when the connection is closed when using other API, particularly event-based ones. The reason this isn't defined in the HTTP spec is because it is not an interoperability issue for the application protocol -- it is an implementation detail that is entirely dependent on the nature of the lower-layer API used by the application. It is the stuff for a good book on network programming. BTW, the reason that clients don't close the connection is because they are generally written to be selfish in regard to network resources. Some clients (Windows-based) never send a FIN -- they always do an RST because they don't want to incur the cost of TIME_WAIT, due to an unusually low fixed limit on mbufs for some version of the OS. This is broken behavior, since the RST is easily lost and the server is left hanging til a timeout expires, but that is fairly typical of clients. Cheers, Roy T. Fielding, Chief Scientist, eBuilt, Inc. 2652 McGaw Avenue Irvine, CA 92614-5840 fax:+1.949.609.0001 (fielding@ebuilt.com) <http://www.eBuilt.com>
Received on Friday, 16 March 2001 17:54:59 UTC