Hi,
>>>
>>> /bookstore/books/http://books.com/id/123
>>>
>>
>> Decoding already happened,
>
> By Jetty? is there no functionality to obtain the "raw" path of the
> URI? For matching of the path you really do need to operate in the
> encoding space.
Yes, indeed, it's possible. I guess I got focused too much on the CXF internal api...
>
> As an example a '/' might be deliberately percent encoded so that it
> does not delineate a path segment. If you work in decoded space (and
> maybe re-encode) you will loose that important information.
>
>
>> 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...
>>
>
> If you want to match the URI, that is not percent encoded and embedded
> in the URI path, then you can do:
>
> @Path("{uri: .+}")
>
> @PathParam("uri") URI u
>
> as we introduced regular expressions, i think in version .10.
>
> If the embedded URI is always percent encoded, as in your example,
> then it can be considered a single path segment and can be matched
> using the default template expressions of @Path.
Cool. Thanks for the helpful response.
Sergey
>
> Paul.
>
>>
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>