httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
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 Wed, 08 May 2013 08:11:10 GMT

Graham Leggett wrote:
> On 08 May 2013, at 9:47 AM, Ruediger Pluem <> wrote:
>> I don't agree with this. The case you mention is only true if the client sends Cache-Control:
>> If this is not the case IMHO 10.5.3 and 10.5.5 apply.
>> And only a cache is required to respond with 504 in this case, not a gateway or a
proxy. So the cache should
>> change a 502 to a 504 in case the revalidation fails. Imagine the case where you
have other backend modules
>> as our proxy modules.
>> So while changing the response to 504 for failed DNS lookups is always correct it
is not for other failures.
>> 10.5.3: The server, while acting as a gateway or proxy, received an invalid response
from the upstream server it
>> accessed in attempting to fulfill the request.
> 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.
> The way I interpret the RFC is that "received an invalid response" described by 10.5.3
occurs when the upstream has said something that the proxy doesn't like, while the unfortunately
named 10.5.5 504 Gateway Timed Out describes a "timely response" which means "at the appropriate
time", meaning a network error of some kind.
> The change above isolates network errors specifically and returns 504 in those cases
only, while leaving 502 for genuine protocol errors, mostly affecting ftp.
> Ultimately Roy is the authority on this?

Good idea. He also knows possible clarifications on that that are work in progress and that
we could already apply.
Roy can you please help us here?



View raw message