Re: HTTP 1.1, proxy servers, and failed connections

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.


Roy T. Fielding, Chairman, The Apache Software Foundation
                  (  <>

                  Chief Scientist, Day Software
                  2 Corporate Plaza, Suite 150
                  Newport Beach, CA 92660-7929   fax:+1.949.644.5064
                  ( <>

Received on Friday, 10 May 2002 22:04:46 UTC