On Jan 29, 2009, at 6:29 AM, Sergey Beryozkin wrote:
>>
> The spec doesn't define which one is chosen, sorting is only specified
> for specificity (x/y > x/* > */*) and q value.
>
> S.B. So would it not make sense to take an original order of Accept
> header values into consideration when all the media types (those in
> Accept and Produces) have the same( or default 1.0 quality factor) ?
> It will make example 2/4 above work as intuitively expected, without
> users having to add quality factors to Accept ?
>
The issue is that then JAX-RS would be assigning additional semantics
to the order of which isn't defined by HTTP.
>> if the above examples are correct then is it the case that Accept
>> header values should not be sorted for the purpose of selecting a
>> method to be invoked ?
>>
>> I’ve got a bit confused – when they actually should be sorted ?
>> Section 3.7.2/3.b mentions Accept, but say nothing about sorting
>> of accept values. Which makes sense,
>>
>> Do they need to be sorted only when a selected method has multiple
>> Produces values, to determine the media type of a given response ?
>>
> The sorting for selecting a method in 3.7.2 step 3 applies regardless
> of whether the @Produce/_at_Consumes is singular or multiple valued.
>
> S.B. - but this sorting applies to @Produce/_at_Consumes values
> available on different matching methods
>
Right. When deciding on which method is the best match you have to
look at all the media types each method can consume and produce.
> The sorting to select a type in 3.8 only applies when the chosen
> method
> can produce more than one media type.
>
> S.B. This applies to the intersection of Accept and a given
> @Produces' values (3.8.5, 3.8.7) ?
Yes.
>
> I guess the answer to my (subject) question is that the spec does
> not require Accept values be sorted
>
You don't have to sort it but you do have to take account of q value
and specificity.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.