FWIW, the way I see it, the proposed change only clarifies the expected behavior of JAX-RS runtime. That's useful for
the developers using JAX-RS. Can you explain where you see the clarification going against HTTP constraints from the
client point of view?
Marek
On 02/13/2012 10:55 PM, Bill Burke wrote:
> Well (I) is ambiguous even with the wildcard, IMO. (II) is covered by the spec no? text/plain would be chosen. I
> don't really care what rules you add, but it does bother me when people write application code like this. Why? Well,
> clients should be written within the constraints of HTTP, not JAX-RS. If a client does:
>
> Accept: text/plain, application/xml
>
> It should expect either back.
>
> On 2/13/12 2:25 PM, Santiago Pericas-Geertsen wrote:
>>
>> On Feb 13, 2012, at 10:18 AM, Bill Burke wrote:
>>
>>> IMO, the ambiguity should be left in. Why? Because the app developer shouldn't be writing interfaces that are
>>> ambiguous in the first place.
>>
>> What about cases (I) and (II) below? Would you consider those ambiguous as well? In some cases, ambiguity depends on
>> which Accept you get in the request; in others it can be determined statically.
>>
>> -- Santiago
>>
>>>
>>> On 2/13/12 8:46 AM, Santiago Pericas-Geertsen wrote:
>>>> Hello Experts,
>>>>
>>>> When adding support for qs during matching (already in EDR2), I realized that step 3b in Section 3.7.2 is a bit
>>>> vague (underspecified). After a few iterations, I came across a more precise (and more complex) description of this
>>>> step. The original text handles the case of compatible types like:
>>>>
>>>> text/plain> text/*> */*
>>>>
>>>> quite well, but it's not precise when comparing incompatible types like:
>>>>
>>>> text/* ? application/xml
>>>>
>>>> Here a few interesting cases:
>>>>
>>>> (I) Request (Accept: text/plain, application/xml)
>>>>
>>>> Resource {
>>>> @GET @Produces("text/*") m1() { ... }
>>>> @GET @Produces("application/xml") m2() { ... }
>>>> }
>>>>
>>>> Which method should be matched in this case?
>>>>
>>>> (II) Same as (I) but with q=0.8 in Accept:
>>>>
>>>> Request (Accept: text/plain, application/xml;q=0.8)
>>>>
>>>> What about in this case?
>>>>
>>>> There are some other cases that are similar to these. In addition, there cases in which matching is clearly
>>>> ambiguous for which the old algorithm was completely silent. The new one suggests that implementations issue a
>>>> warning in these cases.
>>>>
>>>> Place take a look at the re-written step in [1] and provide feedback.
>>>>
>>>> -- Santiago
>>>>
>>>> [1] http://java.net/projects/jax-rs-spec/sources/git/content/spec/spec.pdf?rev=39d35e0fbf5949ba751a40b999900a4ed804852e
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>