Re: JSR311: form-urlencoded question

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 27 Mar 2008 10:38:40 +0100

Bill Burke wrote:
>> 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
> case?

There may be cases where both keys/values are stored in encoded form,
say in a database or are passed to/from an API that requires such
information in encoded form.

>> 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.

An implementation should always perform matching in encoded space,
otherwise there are problems. For example given this URI:


and this:


If you decode you get this:


and then matching on the above will not work as expected.

It is necessary to encode (or validate) the path template, convert to a
regex, then match that against the encoded path.

What if I want to match '{' or '}' characters? or match

Encoded/decoded differences are a source of very subtle bugs in
HTTP-based frameworks that can often lead to errors that appear
unrelated to the actual source of the problem.

>> 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.

I originally thought that but quickly found out that
URLEncoder/URLDecoder don't work as expected for all components of a
URI, they only work for use with URI query components and with the media
type "application/x-www-form-urlencoded".

Unfortunately it is not a general solution and i had to write something
myself to correctly encode/decode/validate components of a URI.


> So, my vote is to remove @Encoded and all encoding methods except for
> URIBuilder.
> Bill

| ? + ? = To question
    Paul Sandoz