Hi Paul,
please see in line...
On Mon, Jul 30, 2007 at 12:11:23PM +0200, Paul Sandoz wrote:
> 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 :-)
You wanted contiguous '/' to be removed from the path? I do not understand why.
To correct possible typos in URIs?
>
> 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.
I think normalization of URIs is ok as long as it affects only dot segments.
(I do not think it is reasonable to use URI templates like "dir1/dir2/../res1"
instead of "dir1/res1")
Attaching a patch for the "URI in URI case", but I think
it is not the right way to go.
~Jakub
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>