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

Reply via email to