Hi Jakub,
Moving to dev_at_jersey ...
Jakub Podlesak wrote:
> The same bug is in [java.net.URI#normalize] as well
> (maybe the root cause since [getPathInfo] just returns a previously set variable value).
>
Feature or bug, i think it might be a bug...
My understanding was that URI.normalize() would remove contiguous '/'
from the path, at least that is what i was using it for. So perhaps i
was using a bug as a feature :-)
From [1] it is clear that './././' should be replaced by '/' but as
Marc says there is nothing about contiguous '/'.
Jersey by default normalizes the URI. If you use a HTTP sniffer you
should notice a redirect. See the handleRequest of
com.sun.ws.rest.impl.application.WebApplicationImpl:
public void handleRequest(ContainerRequest request,
ContainerResponse response) {
final WebApplicationContext localContext = new
WebApplicationContext(this, request, response);
context.set(localContext);
if (resourceConfig.isRedirectToNormalizedURI()) {
final URI uri = request.getURI();
final URI normalizedUri = uri.normalize();
if (uri != normalizedUri) {
response.setResponse(ResponseBuilderImpl.temporaryRedirect(normalizedUri).build());
return;
}
}
Thus we can workaround this by switching off redirection. But, this
requires that we add an option to the APT code that generates the
ResourceConfig class so that the
resourceConfig.isRedirectToNormalizedURI returns false.
Paul.
[1]
http://gbiv.com/protocols/uri/rfc/rfc3986.html#relative-dot-segments
> The following code:
> --cuthere--
> URI baseURI = new URI("http://host/path1//path2");
> System.out.println("baseURI.toString() = " + baseURI.toString());
> System.out.println("baseURI.normalize().toString() = " + baseURI.normalize().toString());
> --cuthere--
>
> Generates:
> --cuthere--
> baseURI.toString() = http://host/path1//path2
> baseURI.normalize().toString() = http://host/path1/path2
> --cuthere--
>
> ~Jakub
>
>
> On Thu, Jul 26, 2007 at 01:19:43PM -0400, Marc Hadley wrote:
>> According to RFC 3986[1], section 3.3 the : is allowed in a path
>> segment so there shouldn't be any reason to encode it. In addition I
>> don't see anything about removing double '/' characters so I think
>> that getPathInfo has a bug.
>>
>> Marc.
>>
>> [1] http://ietf.org/rfc/rfc3986.txt
>>
>> On Jul 25, 2007, at 9:03 AM, Jakub Podlesak wrote:
>>
>>> Hi all,
>>>
>>> I have tried following url:
>>>
>>> http://localhost:8080/Bookmark/resources/users/japod/bookmarks/
>>> ftp://any.net/file.txt
>>>
>>> and noticed, that corresponding HttpServletRequest (tested on
>>> glassfish) provides:
>>>
>>> getRequestURI() ->"/Bookmark/resources/users/japod/bookmarks/ftp://
>>> any.net/file.txt"
>>> getPathInfo()->"/users/japod/bookmarks/ftp:/any.net/file.txt"
>>> ^^^^^^^^
>>>
>>> Please note the missing slash in the latter (ftp:/any.net instead
>>> of ftp://any.net)
>>>
>>> Is this a bug or a feature?
>>>
>>> ~Jakub
>>>
>>>
>>> P.S. It causes an exception in [setURIs] method of
>>> [com.sun.ws.rest.impl.container.servlet.HttpRequestAdaptor]
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>>
>>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109