Hi Sergey
Afaict the behaviour you describe is Jersey specific.
For clients there is a way to express the priority of accept-headers, by
expressing the q-value. What would the advantage be of specifying the
order as being relevant? A client that expects the order to be relevant
is bogus in terms of HTTP-compliance, specifying that jax-rs have to
honor the intention of such a bogus header would at least not foster the
deployment of complaint clients. A minor harm maybe (as proxies are not
supposed to change the order of header values), but before adding spec
lines to better support clients that have expectations beyond what is
specified by HTTP, I'd rather have jax-rs support the full semantics of
the q-value, which isn't only a key for sorting in order of preference
(as per the current jax-rs spec) but indicates a relative degree of
preference, i.e. Accept: application/xhtml+xml,application/xml;q=0.9 and
Accept: application/xhtml+xml,application/xml;q=0.8 have different
meanings in HTTP but are treated the same in jax-rs.
Reto
Sergey Beryozkin said the following on 02/04/2009 04:21 PM:
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>