On Aug 19, 2008, at 10:12 AM, Reto Bachmann-Gmür wrote:
> Marc Hadley wrote:
>> I think I understand now what you are asking for, it sounds quite
>> similar to the Apache mod_negotiation approach:
>> http://httpd.apache.org/docs/1.3/content-negotiation.html
>> As you may know, we're currently in the final sprint to complete
>> the specification, reference implementation and TCK for 1.0 and
>> unfortunately we don't have time to consider new features at this
>> point. However I've added issue 46[1] to keep track of this and
>> we'll consider including support for "quality of source" in the
>> next release of the spec - for 1.0 all sources will be assumed to
>> have the same quality. I'll also ensure that there's nothing in the
>> 1.0 spec that will make it hard to add that feature later.
>> [1] https://jsr311.dev.java.net/issues/show_bug.cgi?id=46
>
> The current spec draft talks about server-side q-value. Forcing
> implementation to ignore a q-parameter on the produced media-type,
> seems like forcing them to a should-level violation of RFC 2616 [1].
>
Recent changes to the spec (not yet published as a draft but available
as the raw .tex in svn) remove server-side q-values but retain support
for q-values in a request Accept.
> So I think the spec should either leave flexibility to
> implementations or else to define that they have to deliver the
> content in the mediatype for which the product of q-value on the
> method, the q-value on the producer and the q-value of the accept-
> header entry is the highest.
For 1.0 we fix the q (or qs) value for methods and providers to 1.0 so
the product is always the same as that specified in the Accept.
> If multiple media-type result to the same q-value product the one
> that is not produced by a provider provided by the implementation is
> used.
>
I don't understand, can you give an example.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.