Re: connection reset by peer messages

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Wedgwood wrote:

> I'm not sure if this is a valid thing for them to do (I looked
> at the HTTP specs and can't find the bit that says if your a shit
> server running on a shit OS your allowed to reset the connection
> where you loaded).

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).

---- RFC2068, section 8.2 Message Transmission Requirements, page 47-48

   If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
   the server, it should assume that the server implements HTTP/1.0 or
   older and will not use the 100 (Continue) response. If in this case
   the client sees the connection close before receiving any status from
   the server, the client SHOULD retry the request. If the client does
   retry the request to this HTTP/1.0 server, it should use the
   following "binary exponential backoff" algorithm to be assured of
   obtaining a reliable response:

  1. Initiate a new connection to the server

  2. Transmit the request-headers

  3. Initialize a variable R to the estimated round-trip time to the
     server (e.g., based on the time it took to establish the
     connection), or to a constant value of 5 seconds if the round-trip
     time is not available.

  4. Compute T = R * (2**N), where N is the number of previous retries
     of this request.

  5. Wait either for an error response from the server, or for T seconds
     (whichever comes first)

  6. If no error response is received, after T seconds transmit the body
     of the request.

  7. If client sees that the connection is closed prematurely, repeat
     from step 1 until the request is accepted, an error response is
     received, or the user becomes impatient and terminates the retry
     process.

   No matter what the server version, if an error status is received,
   the client

  o MUST NOT continue and

  o MUST close the connection if it has not completed sending the
     message.

   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).
------------------------

Note: Netscape 3.01 does NOT implement this.

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