Alamofire: Accept-Language headers are incorrect for some language/region combination

Created on 7 Apr 2017 · 3Comments · Source: Alamofire/Alamofire

Alamofire generates Accept-Language headers using the preferredLanguages property of Locale, which is a combination of the language and the region.

This works well for standard combinations: en-US, fr-FR, fr-CA...

However, if the user chooses a language that does not match the region, we get a combination that cannot be used as Accept-Language.

For example, take a device configured with the following combination:

Language: French
Region: United-States

The first preferredLanguages is then fr-US, which does not represent a real language (there is not a specific version of the French language used in the US).

Thus, the generated Accept-Language contains a value that will not be recognised in many cases. Here is a list of valid codes.

On a French/United-States device, Alamofire generates the following Accept-Language: fr-US;q=1.0, en-US;q=0.9
It is not properly recognised by this PHP function, that tries to find out the best available locale. It will return en instead of fr.

By contrast, Safari iOS makes sure to send a valid Accept-Language:

On a French/United-States device, the sent Accept-Language is fr-fr. (Here is a quick way to know the HTTP Headers sent by a browser).

Ideally, Alamofire should generate the same Accept-Language as Safari.

Xcode version: 8.2.1
iOS version: iOS 10

http headers question

Source

simonliotier

👍2

Most helpful comment

Hi @simonliotier,

Thank your detailed report here...much appreciated. What we all need to keep in mind is that while your use case does not want to receive fr-US, others may. You can always convert fr-US to fr-FR on the server side to do a proper mapping, but you'd never know how to reverse fr-FR to what the user actually has their locale set to which is fr-US.

Alamofire only sets the Accept-Language by default, but you're more than welcome to override it for your particular use case. I don't feel that it would be correct for us to try and make the user's locale more generic.

Cheers. 🍻

cnoon on 17 Jun 2017

👍4

All 3 comments

Thanks for the report! However, I can find no documentation in RFC 7231 that officially states these combinations. Can you point us to any? Otherwise it seems likely we'd need maintain a static map of possible combinations to acceptable ones, which isn't likely something we want to do.