Re: HTTP/1.1

[Chuck Murcko <ch...@telebase.com>]

Ben Laurie liltingly intones:
> 
> '10.4 Client Error 4xx 
> 
> The 4xx class of status code is intended for cases in which the client 
> seems to have erred. If the client has not completed the request when a 
> 4xx code is received, it SHOULD immediately cease sending data and close 
> the connection. Except when responding to a HEAD request, the server 
> SHOULD include an entity containing an explanation of the error 
> situation, and whether it is a temporary or permanent condition. These 
> status codes are applicable to any request method.
> Note: If the client is sending data, a server implementation using TCP 
> SHOULD be careful to ensure that the client acknowledges receipt of the 
> packet(s) containing the response, before the server closes the input 
> connection. If the client continues sending data to the server after the 
> close, the servers TCP stack will send a reset packet to the client, 
> which may erase the clients unacknowledged input buffers before they 
> can be read and interpreted by the HTTP application.'
> 
> Anyone got any idea how we actually implement this?
> 
Sounds weird, but...

Case 1 Client sending request

Server sends 4xx message w/explanation entity unless HEAD request
Server goes into connection close wait/timeout state, ignoring remainder
	of client request, and perhaps does a half close

I think the reset is TCP thinking, and is sent by the TCP stack whenever a
segment arrives that's incorrect for the IP address/port number quad (both
source and destination). That would be the case if the client continued to
send data after the close anyway. I'm assuming that the server would only
initiate the close on the connection after a timeout had expired. The
server might do a half close using shutdown() before this, though.

That's how this reads to me.

chuck
Chuck Murcko	N2K Inc.	Wayne PA	chuck@telebase.com
And now, on a lighter note:
How wonderful opera would be if there were no singers.