Re: Issue 113

On mån, 2008-08-04 at 09:07 +0200, Frank Ellermann wrote:

> The problem of "*" or "*/*" or other Accept-* stars,
> where the implicit or explicit <qvalue> is not the
> smallest <qvalue> in the Accept-* list.

And what is the problem with that?

For Accept-Language the priority is clear.

The most specific language range matching the content tag, with * being
the least specific possible..

* is a very non-specific language tag and sets the qvalue for any other
language. If a more specific language tag has a smaller qvalue than *
then it's a negative saying "Any other language is better than X". 

"en;q=0.1, sv;q=1, *;q=0.5" means

1. sv
2. any other language except for en
3. en

> Including the special cases *;q=0, *;q=1, and *. 

*;q=0 is a no-op as q=0 is the default anyway (except in Accept-Charset
where ISO-8859-1;q=1 is a special implicit default if * is not used...
damn legacy crap)

* and *;q=1 is the same thing as q=1 is the default if the qvalue is not
specified.



But yes there is a slight issue in the description of Accept-Encoding
which uses a slightly different selection priority than the other
Accept* headers where it could be read as *;q=1 is given a higher
priority than gzip;q=0 even if common sense says that "*;q=1, gzip;q=0"
should mean any encoding except for gzip just as it does for the other
Accept* headers..

> This is an issue in its own right, not limited to
> #113 and Accept-Language.  It is a wildcard-qvalue
> issue.  2616bis should tell implementors what this
> means.  If this is hopelessly non-interoperable the
> concept of Accept-* wildcards could be deprecated.

And where does it not tell what the wildcard means or which priority it
gets in relation to other specifications?



Accept-Language which is the header discussed says:

   The special range "*", if present in the Accept-Language field,
   matches every tag not matched by any other range present in the
   Accept-Language field.

Which gives * the lowest possible selection priority.

And further the following is also of relevant to your question:

   A language-range matches a language-tag if
   it exactly equals the tag, or if it exactly equals a prefix of the
   tag such that the first tag character following the prefix is "-".

tag in this context is the language tag of the candidate resource
variant on the server when determining the qvalue of that variant.


Content-Negotiation works in such way that the sever selects the variant
with the highest qvalue as per the Accept* headers evaluated. Variants
with a qvalue of 0 in any dimension is not acceptable. In effect you
start out with the set of all available variants, filter out the
variants with qvalue in any dimension and then sort them to find the
best match..

Specifications do not define the seletion priority between different
Accept* dimensions if they conflict (i.e. Accept, Accept-Language,
Accept-Charset). 

Regards
Henrik

Received on Monday, 4 August 2008 21:49:03 UTC