httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: svn commit: r1480058 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_ftp.c modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Date Fri, 17 May 2013 12:15:08 GMT
Sorry to interfere in the debate with a non-RFC argument but there may be
aftermath by changing a long standing mod_proxy 502 error for almost any
non-recoverable problem with the upstream server.

On Wed, May 8, 2013 at 10:06 AM, Graham Leggett <> wrote:

> Arbitrarily changing a 502 to a 504 on the fly will confuse people, as
> this server isn't the only server that could generate a 502, and 502 might
> be the intended error to be sent to the client.
Some (third-party-)modules/filters/scripts that rely on the 502 error
(bucket) to take an action regarding the upstream server will also be
confused by the commit.

For example ap_http_outerror_filter(), ap_http_chunk_filter() and maybe
others (grep where HTTP_BAD_GATEWAY is checked in the source tree) should
be modified accordingly.

I guess this argument may not be weighty relative to RFC compliance...

 On Wed, May 8, 2013 at 9:47 AM, Ruediger Pluem <> wrote:

> So while changing the response to 504 for failed DNS lookups is always
> correct it is not for other failures.

Do you mean 504, like 503, is admissible for idempotent requests replay or
balancer failover ?
Currently this is not the case...


View raw message