httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: more lingering_close... (tcpdump analysis)
Date Mon, 10 Feb 1997 01:02:04 GMT
On Sun, 9 Feb 1997, Jim Jagielski wrote:

> Marc Slemko wrote:
> > 
> > I have said this a dozen times before.  I am getting tired of saying it. 
> > You don't seem to acknowledge the fact that the socket may not be closed
> > on the client when you send the data but it may be partly closed on the
> > server by the time it arrives at the server.
> > 
> Without l_c() the socket is not partly closed at all (we'll consider
> a socket close atomic right now). Thus, without l_c() the above doesn't
> come into play. The problem I think you are refering to is when

You can consider it atomic all you want, but the fact is that it 
isn't.  It is a four stage process.

> the server goes to close the link and during that period, when all
> looks clear to the client, the client starts sending data. However,
> by the time it reaches the server, the server has closed the connection.
> Thus, the client gets a RST. I have no idea how frequently this
> could occur or what the odds are that this happens.. In any case,
> the client did all that it was supposed to, checked the line, all
> looked OK and then sent the data. It then got a RST and it doesn't
> know why. Now as I read the HTTP1.1 spec, the client should have
> some knowledge of state and know that request 25 went OK but I
> got a RST when sending request 26 and that it should reattempt
> that request... This could be my own misunderstanding of the spec
> (which is quite likely) but surely the client has some responsibility
> for handling errors mid-stream.

The client would have to:

	- automatically retry on a RST
	- not use pipelining when retrying

And the problem would still be there for requests that aren't idempotent.
We can not guarentee that the client will behave as above.  It is not
mandated that it does, therefore to assume it must is a bad thing.

You also have a little problem supporting MS-crap.  It sends a RST to 
terminate the connection normally.  Wanna take bets on the chances
that if it gets a RST it thinks that is a normal close?  I have a 
suspicion that you may (as Roy suggested) just get truncated data
and no error.

You also have to remember that when pipelining is used, HTTP is not
a lock-step protocol.  This means you don't know exactly what request
the error is in response to.  This can, of course, be worked around
by the client but adds network overhead.

For PUTs, current clients don't behave nicely when the get a RST.  I am
not sure it is wise to define the problem away by saying its the clients
problem even though that is not necessarily practical.

View raw message