tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: svn commit: r1005192 - /tomcat/tc6.0.x/trunk/STATUS.txt
Date Fri, 15 Oct 2010 10:51:06 GMT
2010/10/14 Mark Thomas <markt@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


Mime
View raw message