> -----Original Message----- > From: Roy T. Fielding > Sent: Donnerstag, 9. Mai 2013 00:36 > To: dev@httpd.apache.org > 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 > > On May 8, 2013, at 1:11 AM, Ruediger Pluem wrote: > > Graham Leggett wrote: > >> On 08 May 2013, at 9:47 AM, Ruediger Pluem <rpl...@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.
Sorry for being impatient :-) But any update on this Roy? Regards Rüdiger
