Alamofire: Os cabeçalhos Accept-Language estão incorretos para algumas combinações de idioma / região

Criado em 7 abr. 2017 · 3Comentários · Fonte: Alamofire/Alamofire

Alamofire gera Accept-Language cabeçalhos usando a propriedade preferredLanguages de Locale , que é uma combinação do idioma e da região.

Isso funciona bem para combinações padrão: en-US , fr-FR , fr-CA ...

No entanto, se o usuário escolher um idioma que não corresponda à região, obtemos uma combinação que não pode ser usada como Accept-Language .

Por exemplo, pegue um dispositivo configurado com a seguinte combinação:

Idioma: francês
Região: Estados Unidos

O primeiro preferredLanguages é então fr-US , que não representa um idioma real (não há uma versão específica do idioma francês usado nos EUA).

Assim, o Accept-Language gerado contém um valor que não será reconhecido em muitos casos. Aqui está uma lista de códigos válidos .

Em um dispositivo da França / Estados Unidos, Alamofire gera o seguinte Accept-Language : fr-US;q=1.0, en-US;q=0.9
Não é devidamente reconhecido por esta função PHP , que tenta descobrir a melhor localidade disponível. Ele retornará en vez de fr .

Por outro lado, o Safari iOS garante o envio de Accept-Language válidos:

Em um dispositivo da França / Estados Unidos, o Accept-Language enviado é fr-fr . (Esta é uma maneira rápida de saber os cabeçalhos HTTP enviados por um navegador).

Idealmente, o Alamofire deve gerar o mesmo Accept-Language que o Safari.

Versão do Xcode: 8.2.1
Versão iOS: iOS 10

http headers question

Fonte

simonliotier

👍2

Comentários muito úteis

Olá @simonliotier ,

Agradeça seu relatório detalhado aqui ... muito apreciado. O que todos precisamos ter em mente é que, embora seu caso de uso não queira receber fr-US , outros podem. Você sempre pode converter fr-US em fr-FR no lado do servidor para fazer um mapeamento adequado, mas você nunca saberia como reverter fr-FR para o que o usuário realmente tem sua localidade definido para o qual é fr-US .

Alamofire define apenas Accept-Language por padrão, mas você é mais que bem-vindo para substituí-lo para seu caso de uso específico. Não acho que seria correto tentarmos tornar a localidade do usuário mais genérica.

Saúde. 🍻

cnoon em 17 jun. 2017

👍4

Todos 3 comentários

Obrigado pelo relatório! No entanto, não consigo encontrar nenhuma documentação na RFC 7231 que declare oficialmente essas combinações. Você pode nos apontar para algum? Caso contrário, parece provável que precisaríamos manter um mapa estático de combinações possíveis para aquelas aceitáveis, o que provavelmente não é algo que queremos fazer.