www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: URI lossage with ProxyPass
Date Sun, 27 Jun 2004 15:56:08 GMT

Did anyone in mod_proxy land look at this ? I've got more or less the same
questions - but am also a bit unsure what collateral damage the soltuion
outlined below would do (though it 'works for me gov').


On Thu, 17 Jun 2004, Francois-Rene Rideau wrote:

> Dear mod_proxy developers,
> 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
> 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).
> (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 <erwin@cvt12.verfahrenstechnik.uni-stuttgart.de>

View raw message