2010/10/13 Mark Thomas <ma...@apache.org>: > On 13/10/2010 16:57, Konstantin Kolinko wrote: >> 2010/10/6 <ma...@apache.org>: >>> Author: markt >>> Date: Wed Oct 6 18:03:03 2010 >>> New Revision: 1005192 >>> >>> URL: http://svn.apache.org/viewvc?rev=1005192&view=rev >>> Log: >>> Proposal >>> >>> Modified: >>> tomcat/tc6.0.x/trunk/STATUS.txt >>> >>> + >>> +* Fix path parameter handling. Currently the following URL fails with a >>> 404: >>> + http://localhost:8080/examples/jsp/snp;x=y/snoop.jsp >>> + http://people.apache.org/~markt/patches/2010-10-06-path-param-tc6.patch >>> + +1: markt >>> + -1: >>> >> >> I think this is wrong, because a path parameter is not just a pair of >> (name, value), but a triple of (path, name, value), taking into >> account the path segment where it was applied. >> >> The proposed patch strips information on the parameters from the path. >> How the application is supposed to have access to them? > > The short answer is via getRequestURI(). The longer answer is: > > The Servlet Specification defines the following: > requestURI = contextPath + servletPath + pathInfo > > It also states that: > - path parameters are returned by getRequestURI() and getPathInfo() > - contextPath & path parameters are ignored when mapping requests to > servlets > > The specification does not state: > - if the value returned by getContextPath() include path parameters or > not. The implication is that it should not. > - if the value returned by getServletPath() include path parameters or > not. The implication is that it should not. > > If you add removal of /../ sequences, URI decoding and character > decoding then the picture gets even murkier. > > The Servlet expert group has previously indicated [1] that the > specification would be altered to state that getPathInfo() should not > return path parameters and that clarification would be added to confirm > that getContextPath() and getServletPath() should not return path > parameters either. This clarification was never added to the specification. > > I'm not against switching from a pair to a triple for this but a) I'm > not sure many (any?) folks are using path parameters apart from for > session IDs and b) I think the 404 is a more important issue. > > Finally, I'd add that the behaviour varies considerably between > containers in this area and an app's only hope for portability at the > moment is to use getRequestURI(). > > Mark > > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=25015 >
OK. Looks that the patch is working. The snoop.jsp displays the full original path as "Request URI" (aka request.getRequestURI()). Other things there 1) Add http://svn.apache.org/viewvc?rev=1022389&view=rev 2) protected method CoyoteAdapter.parseSessionId(..) is no more used. Deprecate it? 3) path parameters that have no '=' in them are not added to the map. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org