Why use quality values in the HTTP Accept-Language header?

Question

In HTTP, the Accept-Language request header looks like this:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Why were the quality values (q=...) included in the HTTP specification? Couldn't one sort the languages by quality, pick an arbitrary order for languages with the same quality, and leave out any languages with q=0?

Trusting

Probably-- "quality" ratings were probably over-designed. Although the scheme you propose loses some flexibility (e.g. q=0 means absolutely not, while omission could be inferred to mean "not preferred, but not rejected"). – Cowage

@Cowage -MSFT- Well, what is a server supposed to do if it only supports en and a request specifies en;q=0? Serve the page without text? And I can't fathom why a client would say "No English, but any language is fine". – Trusting

@phihag, the specs say that "q=0 means not acceptable": "If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable." (source) – Seigler

@Seigler Yes, that's precisely what I assumed (and you're quoting the exact paragraph of the spec I linked to). See my above comment for two problems with q=0. – Trusting

Answer 1

Interesting question.

The discussion of how this feature came to be is probably buried somewhere in the mailing list archives, for which I could not find a valid link. Your example is not the only problematic one. What is a server to with "fr; q=1.0, en; q=1.0" if it supports both languages. Serve the french because it is first? What about "fr, en; q=1.0"?

Seems to me that an ordered list of language preferences would be a better fit for the problem than the current weighted (and maybe sorted) list. There are too many edge cases where the spec is mum about the expected behavior from an implementation.

At least (some of) the contributors to the spec agree this feature is far from perfect (Key Differences between HTTP/1.0 and HTTP/1.1 - Paper Presented at The Eighth International World Wide Web Conference):

"Because the content-negotiation mechanism allows qvalues and wildcards, and expresses variation across many dimensions (language, character-set, content-type, and content-encoding) the automated choice of the ``best available'' variant can be complex and might generate unexpected outcomes. These choices can interact with caching in subtle ways; see the discussion in Section 3.4.

Content negotiation promises to be a fertile area for additional protocol evolution. For example, the HTTP working group recognized the utility of automatic negotiation regarding client implementation features, such as screen size, resolution, and color depth. The IETF has created the Content Negotiation working group to carry forward with work in the area."

In short I have no real answer but hopefully a participant in the specification process pipes in.

Henleyonthames

This certainly smells like a standards body over-engineering a solution. Theoretically, creating an abstraction which matches one's own language competency as part of some advanced content negotiation sounds desirable. In reality, very few people speak >3 languages, implementers almost certainly would prefer a sorted list, and most website expose a language selection UI: the standard is clearly overbuilt. – Twelvemonth

Answer 2

Keep in mind that Quality Values are used for many other (Accept-*) headers, so while it may not make much sense in context of Accept-Language and feel overcomplicated for selecting languages, the same universal concept is being used for MIME-types (including wildcards for whole groups) and much more, so don't judge just based solely on how it fits the user language selection.

Red

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Nautical