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].
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. 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.
As for consistency something has to be changed anyway, I suggest to
resolve issue 46 right away.
Cheers,
Reto
1.
RFC 2616 says:
The example
Accept: audio/*; q=0.2, audio/basic
SHOULD be interpreted as "I prefer audio/basic, but send me any audio
type if it is the best available after an 80% mark-down in quality."
RFC 2119 says:
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.