[jax-rs-spec users] [jsr339-experts] Re: UriBuilder, forward slashes, path and segments

From: Bill Burke <>
Date: Fri, 01 Jun 2012 12:59:03 -0400

Well, if you automatically encode '/' in a build(), then what if the
user does *not* want the '/' encoded? There is no workaround and they
can't use UriBuilder. Very Bad.

On the other hand, if you do *not* encode '/' in a build(), the work
around is for the developer to manually encode it. Acceptable.

IMO, there are a lot more use cases that would not want to encode '/'.
UriBuilder is going to be used a lot to extract link hrefs.

On 6/1/12 9:36 AM, Markus KARG wrote:
> Gentlemen,
> please keep things simple.
> Strings provided by .path() are template placeholders, while Strings
> provided by .build() are variables content (to be filled into the template
> placeholders).
> So if anybody does NOT expect that .path("{a}").build("a/b") effectively
> produces "a%2FB" in the end has simply done a programming fault.
> Certainly you can punish everybody else by providing another parameter, but
> in fact, omitting the parameter SHOULD break any existing code that expects
> .build("a/b") is NOT providing "a%2FB" as this assumption was simply a wrong
> understanding of the sense of template placeholders and variables content.
> Regards
> Markus
>> -----Original Message-----
>> From: Sergey Beryozkin []
>> Sent: Freitag, 1. Juni 2012 12:43
>> To:
>> Subject: [jsr339-experts] Re: UriBuilder, forward slashes, path and
>> segments
>> On 01/06/12 11:26, Sergey Beryozkin wrote:
>>> Hi
>>> I remember the lively thread we had awhile back about encoding "/"
>>> passed to UriBuilder path and segment methods as if it was yesterday
>>> when we talked about it :-), but I have to admit I've no idea what
>> the
>>> actual conclusion to it was, sorry :-)
>>> I've just had a related query on the users list and I'm coming to the
>>> conclusion that the encoding of "/" should be different depending on
>>> when it is passed to UriBuilder, in case of path() methods:
>>> 1. UriBuilder.fromPath("").path("a/b").build()
>>> should produce "a/b" - as per the JavaDocs of path(...)
>>> 2. UriBuilder.fromPath("").path("{a}").build("a/b")
>>> should produce "a%2Fb"
>>> The reason I think the 2nd variant should produce "a%2Fb" is because
>>> producing "a/b" will be inconsistent with the fact the the matching
>>> algorithm will not actually match "a/b" when we have @Path("{a}") and
>>> I think it should kind of work both ways.
>>> I'm not sure all will agree as one can imagine it can break some
>>> existing code, but please imagine JAX-RS 2.0 Client code doing 1.
>>> above and working against the endpoint with @Path("{a}") and then
>> repeating 2.
>>> and failing against the same endpoint
>> Actually. In both cases, as it currently stands, we will get "a/b" and
>> that will fail to match against @Path("{a}") but I think that the user
>> expectation in the 2nd case will likely be for it not to fail.
>> Marek, I recall you suggested to add an optional flag to build(), to
>> influence whether the "/" should be encoded or not in cases like
>> UriBuilder.fromPath("").path("{a}").build("a/b");
>> example
>> UriBuilder.fromPath("").path("{a}").build(true, "a/b");
>> produces ("a%2Fb") ?
>> thanks, Sergey
>>> For segments, the forward slash has to be encoded all the time:
>>> 1. UriBuilder.fromPath("").segment("a/b").build()
>>> should produce "a%2Fb" - as per the JavaDocs of segment(...)
>>> 2. UriBuilder.fromPath("").segment("{a}").build("a/b")
>>> should produce "a%2Fb"
>>> I do not see any ambiguity here

Bill Burke
JBoss, a division of Red Hat