httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
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 22:36:06 GMT
On May 8, 2013, at 1:11 AM, Ruediger Pluem wrote:
> Graham Leggett wrote:
>> On 08 May 2013, at 9:47 AM, Ruediger Pluem <rpluem@apache.org> wrote:
>> 
>>> I don't agree with this. The case you mention is only true if the client sends
Cache-Control: must-revalidate.
>>> 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?

Unfortunately, I am at the tail end of a long standards meeting and
haven't slept much for three days.  Have you checked to see if the
descriptions changed in HTTPbis p6?  RFC2616 hasn't been relevant
for a while now.

http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html

I'll look at it tomorrow when I have slept a bit.

....Roy


Mime
View raw message