Alamofire: Header Terima-Bahasa salah untuk beberapa kombinasi bahasa/wilayah

Dibuat pada 7 Apr 2017 · 3Komentar · Sumber: Alamofire/Alamofire

Alamofire menghasilkan Accept-Language header menggunakan preferredLanguages properti Locale , yang merupakan kombinasi dari bahasa dan wilayah.

Ini bekerja dengan baik untuk kombinasi standar: en-US , fr-FR , fr-CA ...

Namun, jika pengguna memilih bahasa yang tidak cocok dengan wilayah, kami mendapatkan kombinasi yang tidak dapat digunakan sebagai Accept-Language .

Misalnya, ambil perangkat yang dikonfigurasi dengan kombinasi berikut:

Bahasa: Prancis
Wilayah: Amerika Serikat

preferredLanguages kemudian fr-US , yang tidak mewakili bahasa asli (tidak ada versi khusus bahasa Prancis yang digunakan di AS).

Jadi, Accept-Language dihasilkan berisi nilai yang tidak akan dikenali dalam banyak kasus. Berikut adalah daftar kode yang valid .

Pada perangkat Prancis/Amerika Serikat, Alamofire menghasilkan Accept-Language : fr-US;q=1.0, en-US;q=0.9
Itu tidak dikenali dengan benar oleh fungsi PHP ini , yang mencoba menemukan lokal terbaik yang tersedia. Ini akan mengembalikan en alih-alih fr .

Sebaliknya, Safari iOS memastikan untuk mengirim Accept-Language valid :

Pada perangkat Prancis/Amerika Serikat, Accept-Language adalah fr-fr . (Berikut adalah cara cepat untuk mengetahui Header HTTP yang dikirim oleh browser).

Idealnya, Alamofire harus menghasilkan Accept-Language sama dengan Safari.

Versi Xcode: 8.2.1
Versi iOS: iOS 10

http headers question

Sumber

simonliotier

👍2

Komentar yang paling membantu

Hai @simonliotier ,

Terima kasih laporan rinci Anda di sini ... sangat dihargai. Yang perlu kita semua ingat adalah bahwa sementara use case Anda tidak ingin menerima fr-US , yang lain mungkin. Anda selalu dapat mengonversi fr-US ke fr-FR di sisi server untuk melakukan pemetaan yang tepat, tetapi Anda tidak akan pernah tahu cara membalikkan fr-FR ke lokasi yang sebenarnya dimiliki pengguna set ke yang fr-US .

Alamofire hanya menyetel Accept-Language secara default, tetapi Anda dipersilakan untuk menimpanya untuk kasus penggunaan khusus Anda. Saya merasa tidak tepat bagi kami untuk mencoba dan membuat lokal pengguna lebih umum.

Bersulang. 🍻

cnoon pada 17 Jun 2017

👍4

Semua 3 komentar

Terima kasih atas laporannya! Namun, saya tidak dapat menemukan dokumentasi di RFC 7231 yang secara resmi menyatakan kombinasi ini. Bisakah Anda mengarahkan kami ke salah satu? Kalau tidak, sepertinya kita perlu mempertahankan peta statis dari kemungkinan kombinasi ke kombinasi yang dapat diterima, yang sepertinya bukan sesuatu yang ingin kita lakukan.