On Mon, Sep 16, 2019 at 1:49 PM Mark Thomas <ma...@apache.org> wrote: > > > Alain, > > On 9/13/19 13:37, Alain Sellerin wrote: > >>>> Tomcat version: 8.5 OS: Win10, Linux > > <snip/> > > >>>> I'm facing an issue with an application that is using path > >>>> parameters in conjunction with a RewriteValve. > > <snip/> > > >>>> If the request is : > >>>> http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp The > >>>> servlet response is: Request URI: /sample/subpath/hello.jsp > >>>> > >>>> In this case, Tomcat stripped the path param. I was expecting it to > >>>> be maintained after the rewriting of the URL. > >>>> > >>>> I would like to know if there is a way to preserve path parameters > >>>> from the URL after a rewrite or if it is a bug that I could report > >>>> to Bugzilla. > >>>> > >>>> Feel free to ask me any question if it is not clear enough. > > <snip/> > > > Thank you for your return. As suggested I made a few test with > > different parameters > > > > If the request is : > > http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp > > The servlet response is: Request URI: /sample/subpath/hello.jsp > > > > If the request is : > > http://127.0.0.1:8080/foo/subpath;pathparam=123/hello.jsp > > The servlet response is: Request URI: /sample/subpath/hello.jsp > > > > If the request is : > > http://127.0.0.1:8080/foo/subpath;pathparam=123/hello.jsp > > The servlet response is: Request URI: /sample/subpath/hello.jsp > > > > If the request is : > > http://127.0.0.1:8080/foo/subpath;xyz/hello.jsp > > The servlet response is: Request URI: /sample/subpath/hello.jsp > > > > In all cases, path param is stripped. > > This is (sort of) by design. > > The only mention the Servlet spec makes of path parameters is that: > > <quote> > Path parameters that are part of a GET request (as defined by HTTP 1.1) > are not exposed by these APIs. They must be parsed from the String > values returned by the getRequestURI method or the getPathInfo method. > </quote> > > The issue is that Tomcat needs to remove the path parameters (and a > bunch of other stuff) before mapping requests to security constraints, > Filters and Servlets else you open up a bunch of security > vulnerabilities around security constraint bypass and/or path traversal. > > For similar reasons the RewriteValve also works with the version of the > URI that has had path parameters removed. > > Tomcat provides a very simple non-spec API to obtain path parameters. I > am sure it is possible to retain (it would have to be "re-insert" rather > than "retain") the path parameters as a request passes through the > RewriteValve. However, there are lots of edge cases and it could get > rather messy, very quickly. I am not sure it is practical. > > There are also questions of expected behaviour. > > If "/foo" is rewritten to "/bar" is "/foo;a=b" rewritten to "/bar;a=b" ? > > If "/foo/*" is rewritten to "/bar/too/*" is "/foo/xxx;a=b" rewritten to > "/bar/too;a=b/xxx" or "/bar/too/xxx;a=b", or... ? > > i.e. does the path parameter retain its position in the nth URI segment, > does it stay with the segment it was originally defined on or does it do > something else? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Hi Mark, Thank you for your analysis. It is really helping me. I have the confirmation that it is an expected behavior and that there is a rational behind it. For curiosity, what is the non-spec API to obtain path parameters? Unfortunately I can't use it in my context, I'm not the owner of the underlying webapp and I can't modify its code. Actually we have a fix for the problem but it's not clean and I wanted to check if there is a better solution (in our solution, there is an nginx proxy in front of tomcat that replace all semicolon of the url with an unique sequence of character and in the RewriteValve there is the opposite operation). About all the questions about path param position, I think it is application specific and no assumption can be made. The implementer of rewrite.config have to handle all cases. For example, in my case I know path param cannot be in the first position, and I also know that semicolon can only be used for path param. All that being said, I think it would be an interesting feature to have some "insecure mode" or "power user mode" where the raw url is available in RewriteValve. At least in our case it would have help, but it's probably not a sufficiently widespread scenario in order to bother with it :) For example in Nginx, there is a parameter $uri which is the uri after normalisation and $request_uri which is the uri as requested by the client. Both are available and there is no limitation for rewriting uri. Alain --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
