- From: Roy T. Fielding <fielding@apache.org>
- Date: Fri, 10 May 2002 19:03:32 -0700
- To: Bob Scheifler - SMI Software Development <rws@east.sun.com>
- Cc: ietf-http-wg@w3.org
On Friday, May 10, 2002, at 11:02 AM, Bob Scheifler wrote: > If a proxy server, when initiating a connection to the real server, > gets ECONNREFUSED, EHOSTDOWN, or EHOSTUNREACH, what error should > it return to the client? Some existing proxy servers return 500, It should return 502 (Bad Gateway). > which seems to me particularly unhelpful, some return 503, which > to me doesn't seem equivalent. Is there a generally accepted > theory here? Is the HTTP 1.1 protocol deficient in this regard? HTTP is deficient in not clearly labeling responses as being authoritative (generated by the origin) as opposed to generated by an intermediary. However, 502 at least does that. > For implementing at-most-once semantics for requests, it would > be useful to know definitively (whenever possible) if the > server did not start working on the request. A 500 return doesn't > seem to provide any such guarantee, and it's not clear to me > if a 503 return does (the RFC says the client SHOULD handle 503 > as it would 500, which might be taken to imply that there is no > guarantee). Can someone enlighten me? Thanks. It's hard to guarantee anything, but 6.1 says: HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. Cheers, Roy T. Fielding, Chairman, The Apache Software Foundation (fielding@apache.org) <http://www.apache.org/> Chief Scientist, Day Software 2 Corporate Plaza, Suite 150 Newport Beach, CA 92660-7929 fax:+1.949.644.5064 (roy.fielding@day.com) <http://www.day.com/>
Received on Friday, 10 May 2002 22:04:46 UTC