tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Berry <jbe...@apache.org>
Subject Re: parameters in URL path segments
Date Tue, 22 Aug 2006 03:42:44 GMT

On Aug 21, 2006, at 6:26 PM, James Berry wrote:

> Guys,
>
> Sorry to open up this subject again. I've just read the mails in  
> this thread:
>
> 	http://marc.theaimsgroup.com/?l=tomcat-dev&m=115344110306194&w=2
> 	http://marc.theaimsgroup.com/?l=tomcat-dev&m=115346837428224&w=2
>
> Though I can't say I paid particular attention to the jkmount  
> situation (and so I can't testify as to how treatment of such  
> parameters might affect that), I can say that I'd like to be able  
> to use ;parameter=value in my path segments in a tomcat environment:
>
> 	http://example.com/this;biz=bar;foo/that;v=1.1/whatever
>
> To me, this looks completely valid per rfc 2396, 2616, and 3986,  
> and it's a surprise to me that tomcat strips any path following the  
> first such parameter.
>
> I would like to see tomcat essentially ignore the fact that ';'  
> exists in a path segment, and pass it on into the servlet  
> unmodified to do with as it pleases.

In fact, I don't see any motivation for any special handling of  
semicolon vs any other of the other sub-delims characters, none of  
which tomcat does anything special with. Comma and Plus are allowed  
in path segments, for instance; why is semicolon treated differently?  
The more recent RFCs say that there is nothing special that the  
server/container should do with such a character when it appears in a  
path segment.

Obviously, of course, there would be places where it would be plain  
wrong to place such a parameter/character (if it didn't map to a  
servlet, or to a file, or...) but there are other places (in extra  
path segments in pathInfo, for instance) where the interpretation of  
such characters should NOT BE made by the server, but by the ultimate  
consumer of those bits. Therefore, the server should simply not place  
any special meaning on such characters in any path segment.

James

>
> I'm inspired by the following paragraph in G.4 of rfc 2396:
>
> 	Extensive testing of current client applications demonstrated that
>    the majority of deployed systems do not use the ";" character to
>    indicate trailing parameter information, and that the presence of a
>    semicolon in a path segment does not affect the relative parsing of
>    that segment.  Therefore, parameters have been removed as a  
> separate
>    component and may now appear in any path segment.  Their influence
>    has been removed from the algorithm for resolving a relative URI
>    reference.  The resolution examples in Appendix C have been  
> modified
>    to reflect this change.
>
> And also by the following from rfc 3986:
>
>    Aside from dot-segments in hierarchical paths, a path segment is
>    considered opaque by the generic syntax.  URI producing  
> applications
>    often use the reserved characters allowed in a segment to delimit
>    scheme-specific or dereference-handler-specific subcomponents.  For
>    example, the semicolon (";") and equals ("=") reserved  
> characters are
>    often used to delimit parameters and parameter values applicable to
>    that segment.  The comma (",") reserved character is often used for
>    similar purposes.  For example, one URI producer might use a  
> segment
>    such as "name;v=1.1" to indicate a reference to version 1.1 of
>    "name", whereas another might use a segment such as "name,1.1" to
>    indicate the same.  Parameter types may be defined by scheme- 
> specific
>    semantics, but in most cases the syntax of a parameter is  
> specific to
>    the implementation of the URI's dereferencing algorithm.
> Note that the segment syntax in rfc 3986 explicitly allows sub- 
> delims (through pchar), of which ';' is but one.
>
> James


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message