Re: JSR311: Simplifying/improving support for query and matrix params

From: Stephan Koops <>
Date: Mon, 25 Aug 2008 19:21:25 +0200

+1 for encoded keys in the map and in @*Param.
And if the is a '%' in the key or in @*Param, than it is used as decoded
value, so it will not be decoded, IMO.

best regards

Marc Hadley schrieb:
> We've run into an issue with the way support for query and matrix
> parameters is currently specified. Currently
> UriInfo.getQueryParameters(false):
> 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:
> 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.