Markus,
I did hope you'd reply :-)
On 01/06/12 14:36, 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.
>
I have no problems with the way "/" is managed now.
I thought it was a bit counter-intuitive to get "/" in "a/b" being not
encoded in cases where someone who builds a URI against the target known
to listen at "/{a}/c".
Basically, I'm saying that a service developer will not expect "/{a}/c"
matching "a/b/c", produced by uriBuilder.path("{a}/c").build("a/b").
While the client developer may find it confusing.
Not a huge problem I guess.
Sergey
> 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
>>>
>