Hi Santiago
Please see comments below
On 20/04/15 14:22, Santiago Pericas-Geertsen wrote:
>
>> On Apr 20, 2015, at 9:01 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>
>> Hi Santiago
>>
>> I can not comment on the former as we only have an issue reported by a user and hence I can not give a 100% confirmation, but in a nutshell, it is both.
>>
>> It is both, but ultimately it is important that the spec is clear on the use of 'q' and 'qs'. Otherwise the users will start misusing the *response* content-negotiation primitives for affecting the resource method selection using (Content-Type + @Consumes) as opposed to (Accept + @Produces).
>>
>> Obviously, if the users start using ';qs' on Consumes then they will want to use 'q' on Content-Type but
>>
>> Content-Type: text/bar;q=0.7
>>
>> does not work in the HTTP land...
>>
>> Technically it is easy enough to update the code to do the same process for (Content-Type + @Consumes) where 'q' and 'qs' are checked. But IMHO the spec should do the right HTTP-centric fix.
>
> Ok, I will follow up with the TCK team on the test issue.
Thanks.
>
> As for the spec, I never felt it was confusing on the use of q and qs. Perhaps you can suggest some text to be added to clarify this?
>
What about in 3.7.2 Step 3.b, instead of
(b) ... Let a client media type be of the form n/m;q=v 1 , a server
media type ...
do
(b) ... Let a client (Accept) media type be of the form n/m;q=v 1 , a
server (Produces) media type ...
Something like that ?
Thanks, Sergey
> — Santiago
>
>> On 20/04/15 13:52, Santiago Pericas-Geertsen wrote:
>>> Hi Sergey,
>>>
>>> So is this about the TCK test challenge or are you suggesting a change in the spec to avoid confusion (or both)?
>>>
>>> — Santiago
>>>
>>>> On Apr 20, 2015, at 8:34 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>>
>>>> Hi Santiago
>>>>
>>>> I'm resurrecting this thread on a 370-experts list as we've had a bug reported against CXF where a test expects, given two resource method candidates, selected the one which has a higher 'qs' on a Consumes media type.
>>>>
>>>> IMHO this really needs to be fixed in 370 to avoid the misuse of 'qs'.
>>>>
>>>> Would you be Ok with me opening a JIRA issue ?
>>>>
>>>> Thanks, Sergey
>>>>
>>>> On 15/05/13 14:40, Santiago Pericas-Geertsen wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Yes, you're right. It was not the intention to use qs in @Consumes. We're are looking into it and we'll get back to you.
>>>>>
>>>>> -- Santiago
>>>>>
>>>>> On May 15, 2013, at 5:22 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>>>
>>>>>> Hi Santiago, All,
>>>>>>
>>>>>> I'd like to briefly get back to this thread, see comments in the end of the message
>>>>>>
>>>>>> On 09/04/13 14:46, Sergey Beryozkin wrote:
>>>>>>> On 09/04/13 14:31, Santiago Pericas-Geertsen wrote:
>>>>>>>>
>>>>>>>> On Apr 9, 2013, at 6:05 AM, Sergey Beryozkin<sberyozkin_at_talend.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On 08/04/13 17:06, Sergey Beryozkin wrote:
>>>>>>>>>> Hi Santiago, All,
>>>>>>>>>>
>>>>>>>>>> I have some difficult time reading the section 3.7.2, specifically, the
>>>>>>>>>> 3.7.2/3/b part, it starts from
>>>>>>>>>>
>>>>>>>>>> (1)
>>>>>>>>>>
>>>>>>>>>> "If after filtering the set M has more than one element, sort it in
>>>>>>>>>> descending order as follows. Let
>>>>>>>>>> a client media type be of the form n/m;q=v1 , a server media type be of
>>>>>>>>>> the form n/m;qs=v2 and
>>>>>>>>>> a combined media type of the form n/m;q=v1 ;qs=v2 ;d=v3 , where the
>>>>>>>>>> distance factor d is defined
>>>>>>>>>> below."
>>>>>>>>>>
>>>>>>>>>> and then it mentions, after specifying the terms:
>>>>>>>>>>
>>>>>>>>>> (2)
>>>>>>>>>>
>>>>>>>>>> "Given these definitions, we can now sort M in descending order
>>>>>>>>>> based on
>>>>>>>>>> ≥ as follows7 :
>>>>>>>>>> • Let t be the request content type and CM a resource method’s
>>>>>>>>>> @Consumes
>>>>>>>>>> set of server
>>>>>>>>>> media types, we use the media type max≥ {S(t, c) | (t, c) ∈ {t} × CM }
>>>>>>>>>> as primary key.
>>>>>>>>>> "
>>>>>>>>>>
>>>>>>>>>> Now, given that a 'qs' factor comes into consideration only when a
>>>>>>>>>> client Accept values are checked against @Produces values, why have we
>>>>>>>>>> defined a combined media type in (1) as having 'qs' and then presumably
>>>>>>>>>> using that combined media types in (2), when referring to @Consumes ?
>>>>>>>>>
>>>>>>>>> I think I understand why it is written this way, simply to have a
>>>>>>>>> uniform algorithm text working for both @Consumes and @Produces, with
>>>>>>>>> the Content-Type - @Consumes selection working with both 'q' and 'qs'
>>>>>>>>> set to 1.0 by default.
>>>>>>>>> My concern that some users may get an impression that for example
>>>>>>>>>
>>>>>>>>> Content-Type: text/xml;q=0.8
>>>>>>>>>
>>>>>>>>> can affect the selection of the underlying resource method which IMHO
>>>>>>>>> does not make sense, because if it will affect then the client must
>>>>>>>>> be knowing too much about the implementation details of the server.
>>>>>>>>>
>>>>>>>>> If you share this concern then I can create an ice-box issue to get
>>>>>>>>> some clarifications applied to the selection algo text in 3.7.2
>>>>>>>>
>>>>>>>> Implementations aren't required to implement the algorithm in the
>>>>>>>> same manner, they just need to produce the same results. I'm fine with
>>>>>>>> adding a sentence about quality factors in content types (a new JIRA),
>>>>>>>> but I think it's pretty obvious that's not the intended use of q.
>>>>>>
>>>>>> Right, so 'q' is obviously not for the use with Content-Type.
>>>>>>
>>>>>> Can you please confirm 'qs' is not for the use with @Consumes values ?
>>>>>> I'm seeing a test asserting that adding 'qs' to @Consumes values affects the selection of the methods.
>>>>>>
>>>>>> I think 'q' & 'qs' can work in tandem in order to 1) get the right response type and 2) possibly affect the selection of the method
>>>>>>
>>>>>> Using 'qs' in @Consumes simply as a means to get a method selected is feasible but I wonder if it was actually intended (referring here to the spec text)
>>>>>>
>>>>>> Example:
>>>>>>
>>>>>> Content-Type: text/plain
>>>>>>
>>>>>> @Consumes("text/*") m1()
>>>>>> @Consumes("text/plain;qs=0.8") m2()
>>>>>>
>>>>>> m1 wins apparently. In fact m2() can never even be selected if we take into the consideration that 'q' is not supposed to be used with Content-Type.
>>>>>>
>>>>>> So, do we allow for the use of 'qs' on @Consumes. IMHO it has to be defaulted to 1.0 no matter what custom values are, thoughts, comments ?
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>