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
?
The first “q” parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the 'q' value scale from 0 to 1. The default value is 1.
The Accept header is used to inform the server by the client that which content type is understandable by the client expressed as MIME-types. It is a request type header. This header is used to indicate what character set are acceptable for the response from the server.
Accept header is used by HTTP clients to tell the server which type of content they expect/prefer as response. Content-type can be used both by clients and servers to identify the format of the data in their request (client) or response (server) and, therefore, help the other part interpret correctly the information.
Servers may ignore the Accept header. If you're not returning anything in your response, it's kind of meaningless. It's up to you to decide whether you want to reject requests with Accept headers or not.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With