httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: [PATCH] lingering_close performance improvement
Date Mon, 10 Feb 1997 16:32:47 GMT
>Eh? But the bit of the spec Marc quoted recently seemed to indicate that a
>normal close (i.e. an abort) would be handled correctly by a 1.1 client,
>didn't it?

No, it only described the fallback algorithm for recovery if the client
is capable of knowing which request got the reset.  If a client is
pipelining multiple requests, as in

    5  -->  4  -->  3  -->  2  -->  1  -->

and the server sends the first four responses and closes on the fourth
(for whatever reason), then the connection might get truncated anywhere
in the stream of four responses, depending only upon where the last ACK
was received by the server before it received request 5.

Now, if you really don't care how many times the client needs to repeat
all 5 requests, then you can just close and hope that the client correctly
implements the backoff algorithm in RFC 2068.  On the other hand, you
can do what I proposed and slurp the incoming input until the client
either recognizes the close, stops sending for more than 1 second, or
exceeds the overall hard timeout.  The former results in unnecessary
requests (another form of server overhead) and the user wondering
why on earth it is taking so long to get the first response; the latter
results in the child spending one extra second checking for more input
or a FIN/RST before placing the connection into the RST-if-receive state.

If we had a decent API to work with, we could just wait until the
connection entered FIN_WAIT_2 (client ACK of server FIN) and then
abort the connection ourselves.  That would fix all of our problems.


View raw message