Hi Stephan
> E.g. every browser encodes a space to '+', if you submit a form with
GET
But I think this is what Marc said too - the difference here is that
it's not passed as part of a URI path segments when a form is submitted,
in such cases it would part of a query or a request body. If we have a
URI like
http://foo/bar/id=1+2
then PathParam("/id={id}") should result in '1+2' being passed in...
Cheers, Sergey
-----Original Message-----
From: Stephan.Koops_at_web.de [mailto:Stephan.Koops_at_web.de]
Sent: 10 March 2009 18:19
To: users_at_jsr311.dev.java.net
Subject: Re: Decoding '+' in path parameters
Hi Sergey,
the '+' must definitely be converted to a space. E.g. every browser
encodes a space to '+', if you submit a form with GET
best regards
Stephan
> Hi,
>
> PathParam values are automatically decoded by JAXRS implementations
> unless @Encoded is specified.
> In CXF we just use URLDecoder to decode. If '+' is contained in a
> given value then URLDecoder will produce an empty space instead of
> '+' and one of the CXF users sees it as a bug.
> I reckon that if a user percent-encoded a '+' or added @Encoded
> annotation to a path parameter, then things would work fine.
>
> What I'm kind of confused about is that '+' is listed at [1] as one of
> the reserved characters, and the test says that it is percent-encoded
> values that have to be decoded.
>
> Is CXF JAXRS-compliant (I'm asking it this way to make this post less
> off-topic :-)) in the way it decodes '+' (to space by default) ?
>
> Thanks, Sergey
>
> [1] http://tools.ietf.org/html/rfc3986
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
For additional commands, e-mail: users-help_at_jsr311.dev.java.net