Re: URI lossage with ProxyPass

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

[ message quoted in full and crossposted to dev@httpd ]

> 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.
> =09http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3D29554

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 at=
tempt
>  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 bypa=
ss
>  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=3DPROXY_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 understa=
nds
>  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=
=2E
> 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 don=
e.
>
> Cheers,
>
> [ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.=
tunes.org ]
> [  TUNES project for a Free Reflective Computing System  | http://tunes.o=
rg  ]
> The last good thing written in C was Franz Schubert's Symphony number 9.
>         -- Erwin Dieterich <[email protected]=
e>
>

--=20
Nick Kew