jsr370-experts@jax-rs-spec.java.net

Re: Some issues with section 3.7.2

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Mon, 20 Apr 2015 13:34:00 +0100

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
>>
>>
>>
>>
>