Hi Micha,
The current method of contextual encoding is by design in JAX-RS.
Rather embarrassingly the case you describe never occurred to me or
others on the EG.
Before we modified UriBuilder to support contextual encoding we had
encode(true/false) and isEncoded methods on UriBuilder. The contextual
encoding approach simplified the API.
I am currently not sure how best to resolve this. Could you log an
issue against JAX-RS @:
https://jsr311.dev.java.net/
?
Thanks,
Paul.
On Dec 3, 2009, at 11:03 AM, Micha Werle wrote:
> Hi,
>
> Sending a query using Jersey uses an internal URIBuilder
> implementation, which uses an internal URIComponent's "contextual"
> encoding mode for query parameters. This contextual mode treats any
> data which looks like percent-encoded characters as percent-encoded
> characters.
>
> For example, adding a query parameter:
> param: "dummy" value: "Amount is %30 of the total."
>
> would get encoded and sent as:
> dummy=Amount+is+%30+of+the+total.
>
> On the server, this is then turned into:
> param: "dummy" value: "Amount is 0 of the total."
>
>
> In the current implementation, applications using the Jersey API have
> no (easy) way to send data which just happens to look like
> percent-encoded characters. Of course, knowing this makes it possible
> to avoid this situation, but it does put the onus on the application
> to ensure anything sent is sanitised first. Normally any transport
> layer is responsible for transporting any data entrusted to it
> verbatim to the destination.
>
> So the question is: is the current method of encoding query parameters
> in Jersey by design, or should this be treated as a bug/improvement
> suggestion?
>
> Many thanks,
> - Michael.
>
> --
> "The Glass is neither half-empty nor half-full; it is twice as big as
> it needs to be!"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>