On 17/09/2019 19:00, Alain Sellerin wrote: > On Mon, Sep 16, 2019 at 1:49 PM Mark Thomas <ma...@apache.org> wrote:
<snip/> > 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? It only gets a value for a name. It doesn't provide access to which segment, it doesn't handle multiple instances of the same parameter, etc. http://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/coyote/Request.html#getPathParameter-java.lang.String- > 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). That is as good as anything I can come up with off the top of my head. > 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. I agree. Where things get "interesting" is when the number of path segments change or a segment with a parameter is re-written. > 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 :) The risk with that is generally issues with /../ sequences, %nn encoding etc. It tends to be very easy to bypass the rewrite rule. I don't think there is an easy solution to this. Mark > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
