On 22/10/12 17:42, Marek Potociar wrote:
>
> On Oct 22, 2012, at 5:59 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> On 22/10/12 16:37, Marek Potociar wrote:
>>>
>>> On Oct 22, 2012, at 5:13 PM, Sergey Beryozkin<sberyozkin_at_talend.com
>>> <mailto:sberyozkin_at_talend.com>> wrote:
>>>
>>>> On 22/10/12 16:07, Sergey Beryozkin wrote:
>>>>> On 22/10/12 13:43, Marek Potociar wrote:
>>>>>>
>>>>>> On Oct 22, 2012, at 1:26 PM, Sergey Beryozkin<sberyozkin_at_talend.com
>>>>>> <mailto:sberyozkin_at_talend.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> I know that I'm the last one who still does not get it :-).
>>>>>>>
>>>>>>> Consider the following:
>>>>>>>
>>>>>>> uriBuilder.fromPath("http://localhost").segment("{a}").build("a/b",
>>>>>>> false);
>>>>>>>
>>>>>>> UriBuilder.segment() states that "/" have to be encoded.
>>>>>>
>>>>>> The javadoc of segment() applies to the value passed to the segment().
>>>>>> Not to a template that was added via segment(). IOW, if you passed
>>>>>> "a/b" into segment() directly, it would be encoded.
>>>>>
>>>>> So, to be absolutely clear.
>>>>>
>>>>> By default, irrespectively of whether a given template var was
>>>>> introduced as part of path() or segment() call, the "/" (inside of this
>>>>> var's content) is never supposed to be encoded.
>>>>>
>>>>> The only way to override it, when working with build(), is to use a new
>>>>> flag.
>>>>>
>>>>
>>>> Ouch, it is the other way around,
>>>>
>>>> "NOTE: By default all '/' characters in the stringified values will be
>>>> encoded in path templates, i.e. the result is identical to invoking
>>>> build(Object[], boolean) build(values, true)}. To override this
>>>> behavior use build(values, false) instead."
>>>>
>>>> Why it is a default, I'm not sure, that definitely breaks one of my
>>>> tests - but whatever...
>>>>
>>>> Just need a confirmation please that this rule applies irrespectively
>>>> of the "origin" (ex, a var came from path() or segment())
>>>
>>> Now, I'm not sure what do you want to confirm? I did confirm that "/"
>>> encoding in segment(...) does not apply to template variables and does
>>> apply to string literals in my previous reply, didn't I? Also you quote
>>> javadoc that IMO clearly states the behavior of build(...) method.
>>> Additionally, the build(...) method javadoc also states that:
>>>
>>> "/Values are converted to {_at_code String} using their {_at_code toString()}
>>> method and are then encoded to match the rules of the URI component to
>>> which they pertain/"
>>>
>>> So if you have the same template variable use in different URI
>>> components, it's value will be encoded separately for each component
>>> using the encoding rules of the respective URI components.
>>
>> Stay with with me please on this one.
>>
>> First, I assume this was basically "yes" to my question regarding the origin of the template variable - I've always thought that the rule of the method (ex, that of segment() further qualifies the rules of the encoding of "/").
>>
>> So that is not the case, that is fine,
>>
>> Now given your quote re the rules of the URI component, tell me please (and I'm sorry if that was conveyed earlier):
>>
>> - why the note above states that by default "/" is supposed to be encoded where as the rules of URI Path component let "/" stay as is.
>
> This was done as a fix of a bug filed against JAX-RS specification - Markus can provide more details as he filed the bug. In summary, this way it is more in sync with what you would expect in @Path annotation, were a template variable resolves by default to a single segment. So it makes more sense to consider a single template in a path to be part of a single segment by default and thus encode the "/" by default.
>
> Makes sense?
I'm cautiously optimistic that it does :-)
Cheers, Sergey
> Marek
>
>>
>> Thanks, Sergey
>>
>>
>>
>>>
>>> Marek
>>>
>>>>
>>>> Sergey
>>>>>
>>>>>>
>>>>>>> So one possible output is:
>>>>>>>
>>>>>>> "http://localhost/a%2Fb"
>>>>>>>
>>>>>>> While build() requires this slash to be left as is.
>>>>>>
>>>>>>>
>>>>>>> So the result is then:
>>>>>>>
>>>>>>> "http://localhost/a/b"
>>>>>>>
>>>>>>> If the last output is the right one (has to be really), then I guess
>>>>>>>
>>>>>>> UriBuilder.segment() docs can be improved a bit to state that only
>>>>>>> "/" in the literal expressions have to be encoded by default,
>>>>>>> otherwise the encoding is affected by the new build flag, similarly
>>>>>>> the same clarification needs to be applied to UriBuilder path docs
>>>>>>
>>>>>> Can you please provide a javadoc version that would clarify the
>>>>>> segment() behavior in a way that is, in your opinion, clear&
>>>>>> understandable?
>>>>>>
>>>>> Sure, can do that once I'm 100% clear
>>>>>
>>>>> thanks, Sergey
>>>>>
>>>>>> Thanks,
>>>>>> Marek
>>>>>>
>>>>>>>
>>>>>>> Sergey
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>>
>>>> Blog: http://sberyozkin.blogspot.com
>>>
>>
>>
>