Re: HTTP 1.1, proxy servers, and failed connections

> Resent-Date: Mon, 13 May 2002 18:04:16 -0400 (EDT)
> Resent-Message-Id: <200205132204.SAA15374@www19.w3.org>
> Mime-Version: 1.0 (Apple Message framework v481)
> Cc: ietf-http-wg@w3.org
> To: Bob Scheifler - SMI Software Development <Bob.Scheifler@Sun.COM>
> From: "Roy T. Fielding" <fielding@apache.org>
> Content-Transfer-Encoding: 7bit
> Subject: Re: HTTP 1.1, proxy servers, and failed connections
> Resent-From: ietf-http-wg@w3.org
> Yes, I am sure.  ECONNREFUSED is a response, but not an HTTP response.

If you say so. The spec simply says "invalid response", not
"invalid HTTP response" and not "an invalid HTTP response or an
explicit indication that no HTTP response will ever be received".

> > How do you define "invalid response"?
> 
> Why does that matter?

Are you asking why it matters how terms in a specification are defined?

> You will find that what the user agent needs to do for no-connection is
> identical to what it needs to do for other 502 situations.

Quite the contrary. If I interpret 502 as meaning the upstream server
is non-conforming (broken), I won't ever retry an operation that
gets a 502 result. But if I got the equivalent of ECONNREFUSED back,
I might well retry the operation. That is, if I could get the equivalent
back, which apparently I can't.

In your interpretation, why do both 502 and 503 exist?

- Bob

Received on Monday, 13 May 2002 19:03:21 UTC