RE: HTTP client abort detection ...

Scott Lawrence wrote,
> Miles Sabin wrote:
> > I've been trying (unsuccessfully) to decide whether or not
> > RFC 2616 permits a server to interpret the receipt of a FIN
> > on the incoming-request side of it's connection to a client 
> > as a full client close ... 
>
> I think that it would have been poor form at best for the HTTP 
> WG to ignore the Tcp semantics in that way.  In fact, the 
> client is doing you a favor by sending the FIN as soon as it 
> knows it's done with that half-connection - the server can then 
> close its half right away even if it might otherwise have left 
> it open for persistence, perhaps suffering the time-wait 
> penalty when it times it out (if the client sends the first 
> FIN, then it has to hold the time-wait, and the server 
> doesn't).

If the connection is idle (ie. no pending response), then yes, 
certainly, the server can close immediately.

But it's not so clear if there's (part or all of) a response 
pending, in which case the FIN could be interpreted as only
implying that no more requests will be sent over the connection,
rather than that the client is no longer interested in the
response to the current one.

As far as I can make out the only place in RFC 2616 which has any 
bearing on this scenario is 4.4 Message Length,

  the transfer-length of that body is determined by one of the 
  following (in order of precedence):

  5. By the server closing the connection. (Closing the 
     connection cannot be used to indicate the end of a request 
     body, since that would leave no possibility for the server 
     to send back a response.)

which no more than hints that servers will typically treat the 
receipt of a FIN as an abort. In context it only really rules
out a client using shutdown(fd, 1) as a substitute for chunking
or Content-Length.

I'd be much happier if there were language along the lines of,

  To ensure a reliable response to a request in progress, a 
  client SHOULD keep the transport connection open in both 
  directions until the full response has been received. A client
  MAY close the connection earlier if it does not receive a
  timely response.

  A server SHOULD monitor the network connection for a close
  before or while it is transmitting the response. If the server
  sees the connection close, it SHOULD immediately cease 
  transmitting the response.

  (language pinched from 8.2.2 and elsewhere)

I'm sure the above is the intent, but I just can't see anything 
which confirms it.

Cheers,


Miles

-- 
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/

Received on Monday, 12 March 2001 10:37:55 UTC