- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 06 Jul 95 10:38:57 MDT
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I thought someone explained this to me before, but I've forgotten the
response. If a server MAY close the connection after the response,
then what happens if it takes it a little while to close, and the
client starts up another request on the same connection before seeing
the server close it? Isn't there some kind of race condition?
The client can easily detect this by noticing that the TCP connection
is closed before it receives its response to the second request.
This is guaranteed to be true, because TCP serializes explicit
close operations with data transfer. (I.e., it is not possible
for there to be any ambiguity about where the server's close occurred
relative to the data transmission.)
If a client detects this situation, it should simply reopen the
connection and repeat the request. If the spec only allows the
server to close the connection after sending a response, then
the client will always make progress (that is, always complete
at least one retrieval per TCP connection).
Of course, if the server is thrashing badly, the net performance
would be much worse than with vanilla HTTP. So perhaps a server
using sessions should monitor its recent average-number-of-URLS-per-
connection, and temporarily stop using sessions if this number drops
below a threshold.
-Jeff
Received on Thursday, 6 July 1995 10:46:54 UTC