Accept-Languageヘッダーからロケールを使用してフォールバックを処理する適切な方法は何ですか？アプリケーションは、ロケールからサブタグ（リージョンなど）を削除する前に、要求されたすべてのロケールを完全に照合する必要がありますか？あるいは、たとえリージョンレスのロケールがリクエストに存在しなくても、それは逆に起こりますか？ HTTP specは、一方向または双方向の指示を与えません。受け入れ言語のフォールバックを処理する方法は？
RFC 2616は、2014年にRFC 7230から7235に廃止されました。もうこれ以上参照しないでください。新しいRFCを通じて、Accept-Languageヘッダーは今やRFC 7231, section 5.3.5の権限の下にあります。このセクションでは、RFC 4647, section 3.3を参照しています。これはすでにRFC 2616で承認されています。さらに、RFC 7231では、「基本フィルタリング」マッチング戦略を使用することが明らかになりました。詳細についてはRFC 4647, section 3.3.1で説明しています。
基本フィルタリングは多かれ少なかれプレフィックス検索です。ただし、この検索ではの構文という接頭辞があり、の字句はではありません。アプリケーションは、要求された言語タグのリストを品質の降順で調べる（品質が提供されない場合、これはクライアントによって提供された注文である）、各タグについて、それが確認できるかどうかを見る。いずれも、RFC 7231個の状態を、このstatisfiedできない場合は、次のヘッダフィールドは、応答のために利用可能な 表現の要求及びなしで存在する場合
に一致する言語タグを有する、 オリジンサーバは、無視しますか レスポンスをコンテンツネゴシエーションの対象外であるかのように処理するか、または406 (Not Acceptable)レスポンスを送信して ヘッダーフィールドを尊重することにより、
関連するセクションでは、言語の要件を無視することは、やる気がないことを強調しています。
ただ安全であることを前提としています。ここでの仮定は、基本的な、重み付けされていないロケールのリストです。 – DaSourcerer
必ずしもそうではありません。 'en-US、pt-BR; q = 0.9'のようなものが得られるが、' en-US'は直接入手できない場合、 'pt-BR'を検索する前に' en'に戻すべきでしょうか？ – timwoj
いいえ、以下を参照してください。 'en-US'で表現が見つからない場合、アプリケーションは次に' pt-BR'を試すことが期待されます。クライアントが 'en'を要求した場合、それは' en-US'にマッチします。 – DaSourcerer