tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Berry <>
Subject Re: parameters in URL path segments
Date Wed, 23 Aug 2006 19:07:17 GMT
Jean-Frederic, Bill, Remy,

I didn't get any response to this, but would really like to hear your  
thoughts on this issue of parameters within URL path segments, which  
tomcat current does not allow. Can you give me any feedback?



On Aug 21, 2006, at 8:42 PM, James Berry wrote:
> 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:
>> 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:
>> 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.
>> 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:
For additional commands, e-mail:

View raw message