On Jan 10, 2011, at 4:19 PM, Sergey Beryozkin wrote:
>
> Please look at these two examples, using path calls, just for some
> difference :
>
> 1. UriBuilder.fromUri("http://localhost:8080").path("name/
> {value}").path("%20").build("%20");
>
> will output
>
> http://localhost:8080/name/%2520/%20
>
> 2. UriBuilder.fromUri("http://localhost:8080").path("name/
> %20").path("%20").build();
>
> will output
>
> http://localhost:8080/name/%20/%20
>
> 3. UriBuilder.fromUri("http://localhost:8080").path("name/
> {value}").path("%20").buildFromEncoded("%20");
>
> will output
>
> http://localhost:8080/name/%20/%20
>
> 4. UriBuilder.fromUri("http://localhost:8080").path("name/
> %20").path("%20").buildFromEncoded();
>
> will output
>
> http://localhost:8080/name/%20/%20
>
>
> IMHO the behavior of build() is slightly inconsistent as opposed to
> buildFromEncoded().
> buildFromEncoded() produces the same URI irrespectively of how %-
> encoded values are added to the URI. With build() we see '%' being
> treated differently - and even though now I do finally see why it is
> still a bit confusing :-).
>
> As a user, I'd be more comfortable with using build() if I knew that
> '%' are double encoded, irrespectively of whether '%' was in the
> original literary string or added later on as a var substitution.
> This is why I like buildFromEncoded() because it takes care of the
> contextual encoding if needed but if the user has made an effort and
> provided %-encoded values then those % will stay intact.
>
The reason why we decided that "build" does not contextually encode
parameter values is parameter values might originate from other
sources e.g. a DB or HTML forms etc. where the intention is that these
things cannot be contextually encoded. If you are being "literal" then
we considered it sufficient to do contextual encoded. It is not
encouraged to do string concatenation to stuff values into a URI.
Paul.