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 <minf...@sharp.fm> 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 <rpl...@apache.org> 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... Regards, Yann.
