Hi,
Please see my comments with S.B
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.
S.B.
I initiated this thread after seeing Paul answering to one of Jersey users. In short, the question was why a method annotated with
application/pdf was not selected, it was always the method annotated with text/html which was selected. It proved that the Accept
value was :
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.8, application/octet-stream,application/pdf
Paul's explanation :
> text/html occurs before application/pdf so the former is considered the most acceptable.
So my question is : is it a Jersey specific behaviour ? Or is it what the spec recommends. Both types have the same quality factor.
If it's a Jersey specific behaviour then I've no problems with it. And if yes, then why don't go a step further. HTTP does not
define what happens if equally qualified media types are accepted. What harm to the WEB will JAXRS do if it will introduce some
determinism in this area ? Clients write their applications against services with some expected behaviour - I'm not certain having
some 'undefined' behaviour is a step forward, given how innovative JAXRS has been so far
Thanks, Sergey