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 20:53:11 GMT
Hi Jean-Frederic,

On Aug 23, 2006, at 1:24 PM, Jean-frederic Clere wrote:

> James Berry wrote:
>> 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?
> The question is to which "context" such a request has to be mapped?
> and servlet whatever?

My response is that the tomcat should be completely blind to  
"parameters". Basically, to Tomcat's perspective, they don't exist.  
There is nothing any more special about "this;biz=bar" than  
"this,biz=bar" or "this-biz-bar".

So if there is no context with the name "this;biz=bar" then tomcat  
should do whatever it does when there is no context  
"undefinedcontext". Same with servlet mapping.

Tomcat should be blind to the very existence of parameters because it  
doesn't place any meaning on them. And frankly, since it doesn't, I'm  
probably not very likely to try to give you a url such as that one,  
because there's no reason to make such an ugly url, but I guess it  
makes a good argument, and perhaps a good example.

A more realistic url I might use is:;with=parameters/ 

In such a case, my servlet would would parse the pathinfo and do  
something meaningful with the parameters.

My point, however, is that currently I cannot do the later, because  
tomcat is trying to be too smart. It doesn't support any meaning for  
the parameter syntax, and so, rather than tossing any path that  
contains parameters, it should just be blind to the fact that they  
are there. If somebody creates a url scheme that uses them, Tomcat  
shouldn't stand in their way.


> What do you want to do will biz=bar and foo?
> v=1.1... means that you want version 1.1 of  that, no?
> Cheers
> Jean-Frederic
>> Thanks!
>> James
>> 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:
>>>> dev&m=115344110306194&w=2
>>>> 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:
>>>> 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