Note that I was addicted to the specification of WebTarget.queryParam () of JAX-RS Client.
The specification of WebTarget.queryParam () is [here](https://docs.oracle.com/javaee/7/api/javax/ws/rs/client/WebTarget.html#queryParam-java.lang.String-java. lang.Object ...-). It is a method to set query parameters for WebTarget.
There are some caveats about this method and URI encoding.
The URI template is a function that inserts the path parameter into the part surrounded by {}, but if you think about it, there is a slight problem. The problem is that the query parameter value cannot contain "{" or "}" itself. This is because both "{" and "}" are interpreted as path parameters.
To avoid this, "{" and "}" must be URI-encoded. It means that it should be% 7b and% 7d, respectively.
However, in implementations such as Jersey and RESTEasy, this method performs URI-encoding as described above, so if it is URI-encoded again as it is, it should be converted to% 257b and% 257d. In other words, if you can't use {or}, ...?
The Jersey implementation avoids this by avoiding double URI encoding. Specifically, the rule is that% is not encoded if there are two consecutive hexadecimal characters (0-9a-fA-F) after%. So it's okay to encode {,} as it is.
Conversely, if you happen to have two consecutive hexadecimal characters after%,% will not be URL-encoded.
Therefore, you should always ** always URI-encode yourself before calling queryParam () **.
I don't know what the other implementations are doing. At first glance at the RESTEasy code, it seems that% was not encoded at all.
Of course, the above behavior cannot be read from the JAX-RS specification (implementation dependent). So let's check the operation before using it.
Recommended Posts