tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Path parameters and getRequestURI
Date Wed, 08 Feb 2012 21:42:12 GMT
Hash: SHA1


On 2/8/12 4:34 PM, Mark Thomas wrote:
> On 08/02/2012 21:25, Christopher Schultz wrote:
>> Mark,
>> On 2/8/12 3:37 PM, Mark Thomas wrote:
>>> On 08/02/2012 20:35, Christopher Schultz wrote:
>>>> Can anyone think of a reason I can't just [chop-off
>>>> everything after the first ";"]?
>>> Yes. Path parameters can occur at any part of the path.
>> So a URI could look like this:
>> /context/something;p1=val;p2=val/morestuff
> Yes.

Good to know. I've never seen path parameters in the wild, other than
;jsessionid... which really isn't a path parameter; it feels more like
a hack that was done to avoid interfering with the query string. One
is now just interfering with the path :)

>> Does Tomcat attempt to ignore path parameters when going these 
>> types of matches? (I'd read the code, but the mapper is, as you 
>> know... complex).
> The real trick is knowing that you don't need to look at the
> mapper code :). Of course, it helps if you remember that you wrote
> the code in question ;) Take a look at
> CoyoteAdapter#parsePathParameters()

Yes, it does help :) Thanks for the pointer.

>> Path segments are separated by / characters, so perhaps I could 
>> adjust my "ignore the path parameters" algorithm to work like 
>> this:
>> Starting from the end of the URI, rewind until I hit a "/", then 
>> go forward until I hit a ";", then trim forward from the ";".
> They can also be on the final path segment (and usually are).
>> Or, I could just say "ignore anything like 
>> ';jsessionid=[0-9A-Za-z]*'", but that's a little presumptuous and
>>  potentially fragile as well.
> Indeed.
> Unfortunately, the servlet spec is far from clear on how path 
> parameters should be handled. I hope to get clarity in 3.1 with
> [1]

If I can throw my two cents into the discussion: it would be nice if
the spec either provided methods that unambiguously returned the
uri-path that was matched (with or, I guess, without path parameters
if they are allowed to be a part of the actual match) or provided
additional utility methods could be provided that would make it easy
to filter-out path parameters. Yes, it's a simple thing to do oneself,
but if everyone implements their own (partially broken) filtering,
then the containers are going to get blamed for breaking everything

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message