So this is what our JAX-RS runtime gets before even starting handling
the request :
> Before a root resource class is resolved a fully decoded URI is
> returned by the underlying HTTP stack (Jetty in my example) :
>
> /bookstore/books/http://books.com/id/123
>
Decoding already happened, so for the matching to occur this path will
need to be encoded and decoded (unless @Encoded is there) once again. As
long as it all works for a user I don't mind :-). Perhaps an option of
specifying arbitrary regular expressions will be a better option, give
it a try later on...
Thanks, Sergey
-----Original Message-----
From: Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
Sent: 18 October 2008 01:10
To: users_at_jsr311.dev.java.net
Subject: Re: How to handle encoded URIs (JAX-RS 0.8)
You need to do matching against the normalized and encoded request
URI. Only decode when extracting the value of a parameter (unless its
annotated with @Encoded). In the example below the value of the url
parameter would be
http://books.com/id/123.
Marc.
On Oct 17, 2008, at 12:39 PM, Sergey Beryozkin wrote:
> Hi
>
> At the moment we have problems handling encoded URIs in CXF JAX-RS
> implementation, which for now depends on
> 0.8 api.
>
> I'd like to clarify few things.
>
> Consider this resource class :
> @Path("/bookstore")
> public class Bookstore {
>
> @GET
> @Path("/books/{URL}")
> public Book getBookByURL(@PathParam("URL") String url) {
> return getBook(url);
> }
>
> }
>
> Now consider this GET request :
> http://localhost:9080/bookstore/books/http%3A%2F%2Fbooks.com%2Fid
> %2F123
>
> Before a root resource class is resolved a fully decoded URI is
> returned by the underlying HTTP stack (Jetty in my example) :
>
> /bookstore/books/http://books.com/id/123
>
> According to the section 3.7.3 (June 2008 spec edition), the last
> template variable on the @Path("/books/{URL}") gets replaced by
> "([^/]+?)" group expression.
>
> As such, this pattern is used to find the method, after the root
> class has been resolved :
>
> /bookurl/([^/]+?)(/.*)?
>
> hence when applied, I have 2 groups as a result
>
> first group : 'http:'
> final group : '//books.com/id/123'
>
> As the final group is neither null nor '/', the match can not be done
>
> Can you please advise me on how this can be fixed or what I'm
> missing ? I know in the final api an arbitrary reg expression can be
> specified. but there should be a simple way to do it right in 0.8
> spec too ?
>
> Thanks, Sergey
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
For additional commands, e-mail: users-help_at_jsr311.dev.java.net