On 15/02/12 10:49, Sergey Beryozkin wrote:
> Hi
> On 13/02/12 13:46, 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?
>>
>
> m2() : where is the ambiguity ? m2() has a clear priority, meaning it
> needs to be checked first and its media type will intersect OK with
> Accept and m1() needs to be discarded.
>
> The question is which method needs to be checked first in this case:
>
> @GET @Produces("text/*") m1() { ... }
> @GET @Produces({"application/xml", "foo/*"}) m2() { ... }
>
> and similarly for methods which may have @Consumes.
>
> I'd suggest to clarify that when we have multiple methods with same HTTP
> verb then the one which has more non-wildcard values needs to be tried
> first during either Accept-_at_Oroduces or Content-Type-_at_Consumes
> intersections. Your example will be as well the one I added above would
> be 'taken care of' by this clarification.
>
>
>> (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?
>>
>
> I actually see this one be more unpredictable, but I do not see anything
> ambiguous in the above JAX-RS example. As far as the client is
> concerned, it is fine with either type, As far as the JAX-RS code is
> concerned, the m2() needs to be checked first because it specifies a
> more specific media type. Thus application/xml needs to be returned/
>
However in this case I can understand Bill saying the HTTP constraints
needs to be taken care of as well. Still
> @GET @Produces("text/*") m1() { ... }
> @GET @Produces({"application/xml", "foo/*"}) m2() { ... }
is effectively
@GET @Produces("text/*") m1() { ... }
@GET @Produces({"application/xml;qs=1.0", "foo/*"}) m2() { ... }
so the fact one client might've lowered the chances of application/xml
does not mean it should not be returned when both text/xml &
application/xml are acceptable and the server makes application/xml more
specific
May be I wrong :-) but it seems reasonable to me
Cheers, Sergey