You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by amichalec <an...@gmail.com> on 2009/01/22 21:02:39 UTC
UriBuilder.buildFromEncoded() spec interpretation
Hi,
JAX-RS specification 1.0 for "UriBuilder.build(Object... values)" says that
"All '%' characters in the stringified values will be encoded." This note
matches behavior or URLEncoder, since % must be encoded anyway.
My problem is that for "UriBuilder.buildFromEncoded(Object... values)" spec
says "All % characters in the stringified values that are not followed by
two hexadecimal numbers will be encoded".
My interpretation of spec authors' intention is that: passed values are
already encoded e.g. non-encoded value "foo%bar" must be encoded to
"foo%25bar" and passed here. However if there are any % not matching
percent-with-two-hexes like second % in "foo%25bar%baz". Their encoding
should be forced.
I thing then "foo%25bar%baz" should become "foo%25bar%25baz". If URLEncoder
would be applied once more result would be different, both percent chars
would be affected leading to "foo%2525bar%25baz".
For expected behavior of "buildFromEncoded" is not aligned with URLEncode
behavior. This "extra" safety rule is not necessary for me... but anyway, I
believe implementation should follow spec :)
cheers,
andy.
--
View this message in context: http://www.nabble.com/UriBuilder.buildFromEncoded%28%29-spec-interpretation-tp21612037p21612037.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: UriBuilder.buildFromEncoded() spec interpretation
Posted by amichalec <an...@gmail.com>.
I got confirmation of correct interpretation on jsr311 mailing list, see
https://jsr311.dev.java.net/servlets/ReadMsg?list=users&msgNo=924
BTW there was long discussion on why extra additional "contextual encoding"
is required; see conclusions here:
https://jsr311.dev.java.net/servlets/ReadMsg?listName=users&msgNo=624
subset of these conclusions is applicable in context of buildFromEncoded().
cheers,
andy.
amichalec wrote:
>
> Hi,
> JAX-RS specification 1.0 for "UriBuilder.build(Object... values)" says
> that "All '%' characters in the stringified values will be encoded." This
> note matches behavior or URLEncoder, since % must be encoded anyway.
> ...
>
--
View this message in context: http://www.nabble.com/UriBuilder.buildFromEncoded%28%29-spec-interpretation-tp21612037p21703872.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: UriBuilder.buildFromEncoded() spec interpretation
Posted by Sergey Beryozkin <se...@progress.com>.
Hi Andy
Thanks for sharing your thoughts...It all looks perfectly correct to me.
You might also want to consider sending queries like this one to users@jsr311.dev.java.net for some additional
feedback/clarifications...
Cheers, Sergey
>
> Hi,
> JAX-RS specification 1.0 for "UriBuilder.build(Object... values)" says that
> "All '%' characters in the stringified values will be encoded." This note
> matches behavior or URLEncoder, since % must be encoded anyway.
> My problem is that for "UriBuilder.buildFromEncoded(Object... values)" spec
> says "All % characters in the stringified values that are not followed by
> two hexadecimal numbers will be encoded".
>
> My interpretation of spec authors' intention is that: passed values are
> already encoded e.g. non-encoded value "foo%bar" must be encoded to
> "foo%25bar" and passed here. However if there are any % not matching
> percent-with-two-hexes like second % in "foo%25bar%baz". Their encoding
> should be forced.
>
> I thing then "foo%25bar%baz" should become "foo%25bar%25baz". If URLEncoder
> would be applied once more result would be different, both percent chars
> would be affected leading to "foo%2525bar%25baz".
>
> For expected behavior of "buildFromEncoded" is not aligned with URLEncode
> behavior. This "extra" safety rule is not necessary for me... but anyway, I
> believe implementation should follow spec :)
>
> cheers,
> andy.
> --
> View this message in context: http://www.nabble.com/UriBuilder.buildFromEncoded%28%29-spec-interpretation-tp21612037p21612037.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>