Details
-
Enhancement
-
Resolution: Unresolved
-
Major
-
None
-
4.0.0.Beta6
-
None
Description
The closed bug RESTEASY-1076 mentions that the RESTEasy client's ProcessorFactory ignored the @Encoded annotation for @PathParam and @QueryParam annotated parameters.
This made it impossible to pass certain reserved characters in parameters.
Unfortunately the closed feature RESTEASY-724 merely changed handling of the '/' character during parameter encoding. I would expect the proxy client to be able to pass all data that can also be received in an endpoint denoted by the same interface (1:1 mapping, generic interface). That would require acceptance and proper pass-through of URL encoded values for parameters annotated with @Encoded.
A little digging shows that javax.ws.rs.client.WebTarget provides proper support for all of this via WebTarget.resolveTemplateFromEncoded(). Thus implementing @Encoded on the client side would amount to changing the PathParamProcessor to call WebTarget.resolveTemplateFromEncoded() in the isEncoded == true case.
I am facing this issue in one of my projects where I can not call a RESTEasy endpoint via the proxy client, due to it's inability to pass through already encoded String parameters without encoding them again.
Passing pre-encoded String parameters or pre-encoding objects using a ParamConverter seems to be the only way to get certain characters (';', maybe others) through RESTEasy's URL matching/parsing stages.
As far as I can tell, the suggested change to PathParamProcessor will be completely backward compatible.