On Mon, Jun 22, 2020 at 12:33 PM jean-frederic clere <jfcl...@gmail.com> wrote: > > On 22/06/2020 12:23, Yann Ylavic wrote: > > On Mon, Jun 22, 2020 at 12:13 PM jean-frederic clere <jfcl...@gmail.com> > > wrote: > >> > >>>> > >>>> But there is still something I want to prevent: > >>>> ProxyPass /docs ajp://localhost:8009/docs > >>>> and url like: > >>>> curl -v --path-as-is > >>>> "http://localhost:8000/docs/..;food=bar/test/index.jsp"; > >>>> How do we do that? Do we want a 400 for that? (my proposal do that :-)). > >>> > >>> Why would we 400? > >>> Either there is a mapping for /test[/] and we'll be OK, or there is > >>> none we'll be DECLINED. > >> > >> For the moment I am getting a 200 and the test/index.jsp from tomcat... > > > > Hmm, do you mean that mod_proxy (alias_match_servlet) forwards > > http://localhost:8000/test/index.php in this case, even if there is no > > mapping for "/test" ?? > > Yes :D
I can't reproduce, did you forget "ProxyMappingDecoded off" by any chance? > Well tomcat maps "http://localhost:8080/docs/..;food=bar/test/index.jsp"; > to http://localhost:8080/test/index.jsp which looks bad if you only map > ProxyPass /docs ajp://localhost:8009/docs Sure, but mod_proxy shouldn't forward "/docs/..;food=bar/test/index.jsp" if there is no mapping for "/test", but only when servlet mapping is activated. Otherwise the "normal" mapping applies, which with "/docs" as alias does indeed forward the above.. Remember that currently with my patch, servlet mapping only applies in pre_translate_name hook, before URI-path decoding, because we don't want that "%3B" be decoded first and then interpreted as ';' by servlet mapping (this is not a sub-delims when encoded), thus "ProxyMappingDecoded off" is required. Now that the patches are committed to svn (I just did), I was about to open another thread about this or more generally how we should handle decoding w.r.t. ProxyMappingDecoded, because as it stands ProxyMappingDecoded will affect all location / directory / file / etc.. walks and matchings, since r->uri will remain non-decoded for the whole request handling. That may be what we want, but a mod_proxy directive for this can look a bit surprising since it affects the core handling too. Regards; Yann.
