We've run into an issue with the way support for query and matrix
parameters is currently specified. Currently
UriInfo.getQueryParameters(false):
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/
UriInfo.html#getQueryParameters(boolean)
gets a map of query parameter names and values with the query names
and values in encoded form. Also the @QueryParam.value can be in
encoded form:
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/
QueryParam.html#value()
and the javadoc implies that lookup occurs in encoded space.
One issue with this is that its possible to encode parameter names in
multiple different ways, e.g. foo==f%6fo==f%6f%6f==..., and this can
lead to a situation where an @QueryParam("f%6f%6f") fails to extract a
value for a query param foo in a request URI. The same applies to
querying the map returned from UriInfo.
To solve this requires decoding the values of @QueryParam and the keys
passed to the map returned by UriInfo and then re-encoding them
canonically, which seems like a lot of overhead. Alternatively, and
this is our proposal, we could specify that query param names are
always worked with in decoded form so the value of @QueryParam has to
be in decoded form and the map returned by UriInfo always has the keys
in decoded form. This seems much simpler and doesn't seem to have any
real downside unless we are missing something ?
The same issues apply to matrix params and we think the same proposal
works for those too.
Note that UriBuilder will still contextually encode everything so its
still straightforward to build a new URI with, e.g. the query
parameters from the request provided you are OK with parameter names
being specified in the caonical encoded form rather than the form they
are presented in the request URI.
As you know we are now in the final sprint to 1.0 and I need any
feedback on this sooner rather than later.
Thanks,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.