tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Date Wed, 13 Oct 2010 16:09:18 GMT
On 13/10/2010 16:57, Konstantin Kolinko wrote:
> 2010/10/6  <>:
>> Author: markt
>> Date: Wed Oct  6 18:03:03 2010
>> New Revision: 1005192
>> URL:
>> 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
>> +
>> +  +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

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().



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message