W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: HTTP Session Extension draft

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 06 Jul 95 10:38:57 MDT
Message-Id: <9507061738.AA29283@acetes.pa.dec.com>
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.

Received on Thursday, 6 July 1995 10:46:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC