Hi Paul
It does help, thanks. Please see the comments inline
On Mon, Jan 10, 2011 at 8:30 AM, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
> Hi Sergey,
>
> On Jan 7, 2011, at 6:14 PM, Sergey Beryozkin wrote:
>
> Hi Paul
>
> Many thanks for finding the time to reply and apologies for the the very
> late reply...
> I do believe what you're saying below makes sense to me :-), but I'm still
> not following why
>
> a '%' specified as part of queryParam() calls is not double-encoded;
> however when it is passed as part of replaceQuery() calls the it is double
> encoded. What I'm trying to say that irrespectively of how the query part of
> a given URI has been built, whether using say 5 queryParam calls or using a
> single replaceQuery() call, the end result should be the same
>
>
>
> I think you are conflating two things:
>
> 1) the contextual encoding of literal characters; and
>
> 2) the encoding of parameter values.
>
> I guess so :-)
> Calls to queryParam/replaceQuery are associated with 1 and calls to
> build/buildFromEncoded are associated with 2.
>
> Thus the following must produce equivalent URI values:
>
> 1. UriBuilder.fromUri("http://localhost:8080").queryParam("name",
> "%20").build();
> 2. UriBuilder.fromUri("http://localhost:8080").queryParam("name",
> "%20").buildFromEncoded();
> 3. UriBuilder.fromUri("http://localhost:8080
> ").replaceQuery("name=%20").build();
> 4. UriBuilder.fromUri("http://localhost:8080
> ").replaceQuery("name=%20").buildFromEncoded();
>
> (i.e. like what Jersey does :-) )
>
> OK
> The difference occurs when parameter names in queryParam/replaceQuery and
> corresponding parameter values in build/buildFromEncoded are declared.
>
> The following:
>
> 1. UriBuilder.fromUri("http://localhost:8080").queryParam("name",
> "{value}").build("%20");
> 2. UriBuilder.fromUri("http://localhost:8080").queryParam("name",
> "{value}").buildFromEncoded("%20");
> 3. UriBuilder.fromUri("http://localhost:8080
> ").replaceQuery("name={value}).build("%20");
> 4. UriBuilder.fromUri("http://localhost:8080
> ").replaceQuery("name={value}).buildFromEncoded("%20");
>
> Will output:
>
> 1. http://localhost:8080?name=%2520
> 2. http://localhost:8080?name=%20
> 3. http://localhost:8080?name=%2520
> 4. http://localhost:8080?name=%20
>
> OK.
It does clarify everything. And I think I finally can see what actually I'm
confused about.
Sorry I don't quire recall why I thought the handling of queryParam was
done differently to replaceQuery, I think I hit some issue while working
with the TCK - I'll update as soon as I recall what was it...
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 <
http://localhost:8080/?name=%2520>
2. UriBuilder.fromUri("
http://localhost:8080
").path("name/%20").path("%20").build();
will output
http://localhost:8080/name/%20/%20 <
http://localhost:8080/?name=%2520>
3. UriBuilder.fromUri("
http://localhost:8080
").path("name/{value}").path("%20").buildFromEncoded("%20");
will output
http://localhost:8080/name/%20/%20 <
http://localhost:8080/?name=%2520>
4. UriBuilder.fromUri("
http://localhost:8080
").path("name/%20").path("%20").buildFromEncoded();
will output
http://localhost:8080/name/%20/%20 <
http://localhost:8080/?name=%2520>
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.
Thanks again, Sergey
Hth,
> Paul.
>
>