On Jun 28, 2012, at 6:21 PM, Sergey Beryozkin wrote:
> On 28/06/12 15:34, Marek Potociar wrote:
>>
>> On Jun 1, 2012, at 7:30 PM, Bill Burke wrote:
>>
>>> 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 '/'.
>>
>> yes.
>>
>> FWIW, the actual fix for the issue is the new set of methods being added
>> to the UriBuilder API as discussed earlier:
>>
>> build(Object[] values, boolean encodeSlashInPath)
>> buildFromMap(Map<String, ?> values, boolean encodeSlashInPath)
>
> OK. Now that I've hit this issue myself I see the value.
>
> I'm assuming that it won't apply to template variable substitutions 'associated' with UriBuilder#segment calls
Sure it will why shouldn't it? UriBuilder.segment(...) is good for appending properly encoded single path segments, but should not affect the way path templates are treated.
As Markus correctly pointed out at one point, there is no such thing as path segment URI component, there's only a path component. And at the time when URI templates are filled with values via one of the build methods, it does not really matter how the templates got into the path component. So IMO we need to treat all path templates same way (and consistently with how path templates are treated in @Path annotation) regardless of how they got into the path. Otherwise we'll just produce more confusion in these edge cases.
So just to reiterate, the clarified rules for encoding values of uri templates are:
- encode each value contextually based on the URI component containing the template
- in path templates, by default, encode also slashes (i.e. treat all path templates as part of a single path segment, to be consistent with @Path annotation templates)
- for special cases when the slash encoding in path templates is not desired, users may use the newly added build methods to override the default behavior
Marek
>
> Cheers, Sergey
>
>
>>
>> Marek
>>
>>>
>>> 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
>>>>>> <mailto: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
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com