Subject: HTTP client abort detection ...

From: Miles Sabin <[email-masked]>
Date: Mon, 12 Mar 2001 17:20:43 -0000

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 ... allowing it to immediately stop any
request processing, and possibly avoid a RST due to the arrival 
of unwanted response data at the client.

Unfortunately I can't convice myself that this is safe. I can't
see anything in the spec which says a client isn't allowed to
send a request, then shutdown(fd, 1), and then still expect the
server to continue request processing and send a response.

Is there lore on this? Are clients within their rights behaving
in this way? Do any real clients behave this way? Are there any
servers out there which aggressively monitor for client closes
and abort connections in the way I described above?

Opinions most welcome.

Cheers,

Miles

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

---

From: Miles Sabin <[email-masked]>
Date: Mon, 12 Mar 2001 18:30:01 -0000

Scott Lawrence wrote,
> Miles Sabin wrote:
> > 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