Alamofire: Les en-têtes Accept-Language sont incorrects pour certaines combinaisons langue/région

Créé le 7 avr. 2017 · 3Commentaires · Source: Alamofire/Alamofire

Alamofire génère des en-têtes Accept-Language en utilisant la propriété preferredLanguages de Locale , qui est une combinaison de la langue et de la région.

Cela fonctionne bien pour les combinaisons standard : en-US , fr-FR , fr-CA ...

Cependant, si l'utilisateur choisit une langue qui ne correspond pas à la région, nous obtenons une combinaison qui ne peut pas être utilisée comme Accept-Language .

Par exemple, prenons un appareil configuré avec la combinaison suivante :

Langue : Français
Région : États-Unis

Le premier preferredLanguages est alors fr-US , ce qui ne représente pas une vraie langue (il n'y a pas de version spécifique de la langue française utilisée aux États-Unis).

Ainsi, le Accept-Language généré contient une valeur qui ne sera pas reconnue dans de nombreux cas. Voici une liste de codes valides .

Sur un appareil français/américain, Alamofire génère les Accept-Language : fr-US;q=1.0, en-US;q=0.9
Il n'est pas correctement reconnu par cette fonction PHP , qui essaie de trouver la meilleure locale disponible. Il renverra en au lieu de fr .

En revanche, Safari iOS s'assure d'envoyer un Accept-Language valide :

Sur un appareil français/américain, le Accept-Language envoyé est fr-fr . (Voici un moyen rapide de connaître les en-têtes HTTP envoyés par un navigateur).

Idéalement, Alamofire devrait générer le même Accept-Language que Safari.

Version Xcode : 8.2.1
Version iOS : iOS 10

http headers question

Source

simonliotier

👍2

Commentaire le plus utile

Salut @simonliotier ,

Merci pour votre rapport détaillé ici... très apprécié. Ce que nous devons tous garder à l'esprit, c'est que même si votre cas d'utilisation ne veut pas recevoir de fr-US , d'autres le peuvent. Vous pouvez toujours convertir fr-US en fr-FR côté serveur pour faire un mappage correct, mais vous ne saurez jamais comment inverser fr-FR en ce que l'utilisateur a réellement ses paramètres régionaux défini sur fr-US .

Alamofire ne définit que le Accept-Language par défaut, mais vous êtes plus que bienvenu pour le remplacer pour votre cas d'utilisation particulier. Je ne pense pas qu'il serait correct pour nous d'essayer de rendre les paramètres régionaux de l'utilisateur plus génériques.

À votre santé. ??

cnoon le 17 juin 2017

👍4

Tous les 3 commentaires

Merci pour le rapport ! Cependant, je ne trouve aucune documentation dans la RFC 7231 qui indique officiellement ces combinaisons. Pouvez-vous nous en indiquer ? Sinon, il semble probable que nous aurions besoin de maintenir une carte statique des combinaisons possibles aux combinaisons acceptables, ce qui n'est probablement pas quelque chose que nous voulons faire.