Re: JSR311: form-urlencoded question

From: Bill Burke <>
Date: Wed, 26 Mar 2008 09:37:54 -0400

Paul Sandoz wrote:
> Bill Burke wrote:
>> Me too. :) decoded keys always.
> I assumed and implemented encoded keys and values for
> UriInfo.get*Parameters(true) and UriInfo.getPathSegments(true). Namely
> that you if ask for something in encoded form you get everything in
> encoded form. This reduces possible sources of confusion and bugs and
> the main idea of encoded form was so that a more advanced developer
> could work consistently in encoded form for all such information
> extracted from the URI.
> UriBuilder.queryParam encodes the value and name if the encode property
> is set to true, otherwise validates the value and name if set to false.
> If query keys are decoded but query values are not then it is hard to
> use UriBuilder.queryParam consistently with
> UriInfo.getQueryParameters(false).

Yeah, I guess you're right. My thought was, why would anybody ever
encode a key to access a specific value in the map? In general, I don't
see how these encoded maps would be very useful. Can you provide a use

> Looking more closely i found some issues because the *Param names are
> not specified to be in encoded or decoded form, and i did not assume
> either way when implementing.
> The JavaDoc does not define if @*Param names should be in encoded or
> decoded form. Same goes for @DefaultValue. Note that @Encoded does not
> apply to values of @Path, for example:
> @Path(value="x%20y", encode=false)

BTW, why would anybody every want to put encoded values within a @Path?
  IMO, this @Path(encode) should be removed. The container should
always decode the incoming URI before trying to match.

> We also need to specify the encoded/decoded form for:
> UriInfo.getAncestorResourceURIs
> and perhaps be consistent with other methods with a boolean parameter.

Except for URIBuilder, why even have the option to have things encoded?
  I don't see developers wanting to use it very much, if at all. If
they want things encoded, its just as easy to call URLEncoder.encode().
  Which would be a rarity in the first place.

So, my vote is to remove @Encoded and all encoding methods except for


Bill Burke
JBoss, a division of Red Hat