On Thu, 17 Jun 2004, Francois-Rene Rideau wrote: [ message quoted in full and crossposted to [EMAIL PROTECTED] ]
> I have experienced quite some trouble due to design bugs in ProxyPass, > and have proposed a patch for apache 1.3. > The very same bugs are present in apache 2.0, and a similar fix could be used. > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29554 I've reviewed this in the context of httpd-2.1, and it looks good to me with essentially the same patch. It works on your testcase, and I'm 99% satisfied that it doesn't break anything. Ready to commit if we can answer the remaining question: should proxy_fixup be removed altogether: > > Can you tell me if you'll fix the official mod_proxy, > either using my patch or otherwise? > > > The bug symptoms are that > (1) when a request to a ProxyPass host contains %3A, the %3A is expanded > to a colon, which yields an incorrect HTTP URL that confuses the remote host. > (2) when a request to a ProxyPass host contains %2F, apache rejects the > request with a 404 without even contacting the remote host. > > The bug causes are that > (1) function modules/proxy/mod_proxy.c:proxy_fixup() makes a misguided attempt > at URI canonicalization. It should definitely not try to > when using PROXY_PASS, and probably not in STD_PROXY mode either. > Since I don't understand all the ins and outs, my patch only adds a bypass > in the case of PROXY_PASS, but I believe the whole function should be > scrapped altogether (whoever checks in the patch should ponder that). Graham Leggett's reply seems to support that, and having figured out what you are talking about, I agree. Can anyone see why proxy_fixup should not be removed altogether? > (2) r->proxyreq=PROXY_PASS is declared too late, only in > modules/proxy/mod_proxy.c:proxy_trans(), so that > main/http_request.c:process_request_internal() already messed up > with the URL, not realizing there is a proxy request going on. > Consequently, the ProxyPass alias detection MUST happen not in > modules/proxy/mod_proxy.c:proxy_trans() but in > modules/proxy/mod_proxy.c:proxy_detect(). > This may or may not interfere with funky rewrites that some people > may want to do before or after a ProxyPass is used. Someone who understands > such issues should step in and tell. Maybe my change introduces some > subtle incompatibilities in *actually deployed* setups, but I would bet not, > and some mechanism could be devised to restore proper behaviour > for those who would need such a feature. > > I hope my patch doesn't break any expected behaviour, but I can't be sure. > What I'm certain of is that ProxyPass is quite broken without my patch. > Please consider merging this patch into apache, and tell me when it's done. > > Cheers, > > [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] > [ TUNES project for a Free Reflective Computing System | http://tunes.org ] > The last good thing written in C was Franz Schubert's Symphony number 9. > -- Erwin Dieterich <[EMAIL PROTECTED]> > -- Nick Kew
