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