You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2010/10/06 20:03:03 UTC
svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
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
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1005192&r1=1005191&r2=1005192&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Oct 6 18:03:03 2010
@@ -232,3 +232,9 @@ PATCHES PROPOSED TO BACKPORT:
http://svn.apache.org/viewvc?rev=1004869&view=rev
+1: kkolinko
-1:
+
+* 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:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/10/13 Mark Thomas <ma...@apache.org>:
> 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
I will think more on it and do some testing, what of our APIs are exposing them,
but just from reading RFC 3986 ch.3.3 [1] I think the representation
of them as a simple HashMap<name,value> is inadequate.
http://tools.ietf.org/html/rfc3986#section-3.3
> and b) I think the 404 is a more important issue.
Is it possible to fix the client that sends those requests? Or apply a
Valve/Filter?
Though, well, I can imagine a scenario that this issue may be seen
a) start Tomcat and make a bookmark that includes jsessionid in its path
b) reconfigure Tomcat to use a different name for jsessionid parameter
c) the bookmark no longer works.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Rainer Jung <ra...@kippdata.de>.
On 15.10.2010 12:51, Konstantin Kolinko wrote:
> 2010/10/14 Mark Thomas<ma...@apache.org>:
>> On 14/10/2010 09:02, Konstantin Kolinko wrote:
>>> 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
>> +1
>>
>>> 2) protected method CoyoteAdapter.parseSessionId(..) is no more used.
>>> Deprecate it?
>> +1
>>
>>> 3) path parameters that have no '=' in them are not added to the map.
>> Could you find a definitive reference on how path parameters are defined
>> for HTTP (i.e. use ';' as the separator, value required/optional,
>> defining multiple values for one parameter, path segment is/isn't
>> significant etc.)? I looked but couldn't find anything.
In addition to what Konstantin wrote: though I couldn't find a good
authoritative reference concerning path parameter definition for HTTP
URIs, I stumbled over a Tomcat discussion from 4 years ago:
http://marc.info/?t=115343016400001&r=1&w=2
http://marc.info/?t=115621014500001&r=1&w=2
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/10/14 Mark Thomas <ma...@apache.org>:
> On 14/10/2010 09:02, Konstantin Kolinko wrote:
>> 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
> +1
>
>> 2) protected method CoyoteAdapter.parseSessionId(..) is no more used.
>> Deprecate it?
> +1
>
>> 3) path parameters that have no '=' in them are not added to the map.
> Could you find a definitive reference on how path parameters are defined
> for HTTP (i.e. use ';' as the separator, value required/optional,
> defining multiple values for one parameter, path segment is/isn't
> significant etc.)? I looked but couldn't find anything.
>
There is RFC 3986 ch.3.3 [1] that I already mentioned,
[1] http://tools.ietf.org/html/rfc3986#section-3.3
but that is not specific for HTTP.
[1] also shows quite different examples, such as "name;v=1.1" and "name,1.1".
The HTTP1.1 RFC 2616 ch.3.2.2
[2] http://tools.ietf.org/html/rfc2616#section-3.2.2
[[[
The semantics
are that the identified resource is located at the server listening
for TCP connections on that port of that host, and the Request-URI
for the resource is abs_path (section 5.1.2).
]]]
so abs_path is directly sent to the server as Request-URI.
from ch.5.2 of the same RFC 2616
[[[
5.2 The Resource Identified by a Request
The exact resource identified by an Internet request is determined by
examining both the Request-URI and the Host header field.
]]]
so I think that is up to the server how to interpret the Request-URI
and in Tomcat case the "server" is Tomcat+webapp and we pre-interpret
that Request-URI before passing it to our applications.
My thought regarding Request.pathParameters map is that it is
inadequate, but at least it provides an indication that a parameter
was present. Though request.getRequestURI().indexOf() will provide
such indication as well.
I would prefer if your issue can be fixed without introducing this
pathParameters map, but I actually do not mind much if the map can be
useful for someone. Maybe I am resenting that we are using good names
for it, while we might want to refine the API in the future.
BTW, will it affect security, that a path is callable by different URIs?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Mark Thomas <ma...@apache.org>.
On 14/10/2010 09:02, Konstantin Kolinko wrote:
> 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
+1
> 2) protected method CoyoteAdapter.parseSessionId(..) is no more used.
> Deprecate it?
+1
> 3) path parameters that have no '=' in them are not added to the map.
Could you find a definitive reference on how path parameters are defined
for HTTP (i.e. use ';' as the separator, value required/optional,
defining multiple values for one parameter, path segment is/isn't
significant etc.)? I looked but couldn't find anything.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Konstantin Kolinko <kn...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Konstantin Kolinko <kn...@gmail.com>.
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?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org