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:
http://host/path/http:%2F%2Fhost%2Fpath/morestuff
and this:
@Path("path/{uri}")
If you decode you get this:
http://host/pre/http://host/path/post/value
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
"path/file:%2F%2F{path}"
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.
Paul.
> So, my vote is to remove @Encoded and all encoding methods except for
> URIBuilder.
>
> Bill
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109