- From: Bob Scheifler - SMI Software Development <rws@east.sun.com>
- Date: Mon, 13 May 2002 19:03:00 -0400 (EDT)
- To: fielding@apache.org
- Cc: ietf-http-wg@w3.org
> 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