On Feb 4, 2009, at 10:39 AM, Reto Bachmann-Gmür wrote:
> 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.
>
Just checking - are you referring to the lack of support for quality
of source (issue 46) or something else ?
Thanks,
Marc.
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.