CODEWITHSUNDEEP
httphttp-headerslocale
timwoj
timwoj

Reputation: 388

How to handle accept-language fallback?

What is the proper method of handling fall back with locales from the Accept-Language header? Should an application attempt to match all requested locales perfectly before removing any subtags (regions, etc) from the locales? Or should it happen the other way around, even if those region-less locales don't exist in the request? The HTTP spec gives no indication one way or the other.

Upvotes: 1

Views: 745

Answers (1)

DaSourcerer
DaSourcerer

Reputation: 6606

RFC 2616 has been obsoleted by the RFCs 7230 to 7235 back in 2014. Please do not refer to it any longer. Through the new RFCs, the Accept-Language header is now under authority of RFC 7231, section 5.3.5. Said section is referring to RFC 4647, section 3.3, which has already been authorative over RFC 2616. Furthermore, RFC 7231 makes it clear that the "Basic Filtering" matching strategy is to be used which is described in detail in RFC 4647, section 3.3.1.

Basic Filtering is more or less a prefix search. Note, however, that this search is looking for a syntactical prefix, not a lexical one. An application is expected to go through the list of requested language tags in descending order of quality (if no qualities are provided, this is the order provided by the client) and see for each tag if it can be statisfied. If none can be statisfied, RFC 7231 states this:

If the header field is present in a request and none of the available representations for the response have a matching language tag, the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation or honor the header field by sending a 406 (Not Acceptable) response.

The relevant section does stress out that ignoring the language requirement were the saner thing to do, though.

Upvotes: 1

Related Questions