On 6/2/2010 2:29 PM, Ken Paulsen wrote:
>
>
> On 06/02/2010 11:59 AM, Bill Shannon wrote:
>> Ken Paulsen wrote on 06/ 2/10 10:49 AM:
>>>
>>> I think the reason it is decoded is this: The Container receives a
>>> request like "/foo/at%40test.html" which then must be decoded to serve
>>> up a file named "/foo/at_at_test.html". '@' and many other characters not
>>> allowed in URLs must be encoded when they're used in a file name, so
>>> the
>>> container must decoded them *before attempting to resolve them*.
>>
>> I guess the issue is whether that decoding should be done before
>> interpreting the string to choose the destination servlet or
>> whether the destination servlet (e.g., the default file handling
>> servlet) should do the decoding before using the value.
>>
>> I would expect the Servlet spec to say something about this. If
>> it requires the decoding to be done before passing the value to the
>> Servlet, there may be little we can do.
>>
>> If there's a mapping for /foo/bar/*, should a URL of the form
>> /foo%2Fbar/index.html match it?
>
> Because it's %2F, I would think not. But, what about a mapping for
> /foo_at_bar/*, should /foo%40bar/index.html match it? I think yes
> (assuming @ is legal... if not, replace with some valid unicode
> character). The % encoding is required in the URL, so it must be
> decoded before attempting to match the path. That's just my 2 cents
> though... and yes, we should see what the spec.
Chapter 12 of the Servlet 3.0 spec talks about Mapping Requests to
Servlets. Unfortunately, it doesn't say anything about these cases. It
does that a '/' is used for path mapping and that other characters must
have an exact matches.
Regarding your second case, the spec says that URLs in the deployment
descriptor are assumed to be in URL-decoded form. (page 102). But given
this, maybe the proper way for the servlet container to match URLs is to
encode the URL from the deployment descriptor and match that with the
URL rather than decoding the URL and matching it with the deployment
descriptor.
Tom