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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
