Well, I'm wrong, there is a workaround if you want to *not*
automatically encode '/', but its unclear which one would give the
desired behavior:
build() v.s buildFromEncoded()
buildFromEncoded should probably only encode illegal characters and '%',
if not followed by two hexadecimal numbers and not '/'.
On 6/1/12 12:59 PM, Bill Burke wrote:
> 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 [mailto:sberyozkin_at_talend.com]
>>> Sent: Freitag, 1. Juni 2012 12:43
>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>> 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
http://bill.burkecentral.com