Re: connection reset by peer messages

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

On Tue, May 05, 1998 at 07:41:25PM +0000, Henrik Nordstrom wrote:

> Yes, dropping a connection before sending a response is allowed. I have
> some doubts on if it really is Squids responsibility to retry the
> connection, of if it should be left to the client (prematurely closing
> the client connection without any reply).

[...]

> An HTTP/1.1 (or later) client that sees the connection close after
> receiving a 100 (Continue) but before receiving any other status
> SHOULD retry the request, and need not wait for 100 (Continue)
> response (but MAY do so if this simplifies the implementation).

(Warning: I'm not sure I completely follow this... so I might be confused
here).

I don't think this is the case for the IIS servers though. The server
accepts an initial connection and then close it before sending _any_ data
whatsoever. I'm not sure if this is before or after a request is received
(that distcintion is kind a pointless anyhow when the request is smaller
than the window size).

Now, this may or may not be acceptable, but the fact is this happens and
that the squid emits a 'connection reset by peer' response when Microsoft
Proxy II seems to retry these. (I've not actually confirmed it does other
than I don't see errors that would indicite this when using it).

I agree that squids probably do the right thing and the client should deal
with it as appropriate, but then some people start whacking reload which can
deminish the effectiveness of the cache.

If anything, a confugraiton option to retry with some kind of backoff would
b e a good idea IMO. Either that or a minimum ttl for documents so that
hitting reload would not be so much of an issue, although I can't see how to
make this work without breaking other stuff).

-Chris

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:49 MDT