Summary

  • 1997 年の HTTP/1.1 RFC 2068 は、ブラウザーが Accept-Language に希望する言語と優先度を記す方法を示した。
  • 言語で版を選んだサーバーが Vary: Accept-Language を返せば、キャッシュは次の要求でその言語条件を照合してから保存済みの版を再利用する。

1997 年 1 月の RFC 2068には、デンマーク語、英国英語、ほかの英語を順に好むという例が載る。q の値が希望の強さを表す。ブラウザーは URL と一緒にこの注文票を送れるので、サーバーは最初の一ページから適切な版を選べる。言語選択画面で客を立たせて待たせる必要はない。

ただし、同じ /news を二人が読む。最初の人にはデンマーク語、次の人にはフランス語が向いているかもしれない。間の共用キャッシュが URL だけを見て保存したページを返せば、住所は正しくても版は違う。何を選んだかと同じくらい、何を手掛かりに選んだかを伝える必要がある。

その伝言が Vary だ。現在の HTTP Semanticsは、Vary: accept-language が応答を選ぶ際に参照された要求フィールドを示すと説明する。HTTP Caching の RFC 9111は、指定されたフィールドが保存時の要求と一致しないなら、再検証なしにその応答を使ってはいけないと定める。棚には本だけでなく、誰向けに選んだ本かという札も付く。

札を忘れたときの失敗も RFC 9111 が挙げている。既定の応答だけ Vary を付け忘れると、もっと適した版がある後続の要求にも既定版が選ばれうる。翻訳の誤りではない。配達の根拠を伝え損ねた結果、手際のよいキャッシュが同じ本を出し続ける。

応答側の Content-Language は、届いた内容がどの言語の読者に向くかを示す。RFC 9110での役割は明快だ。Accept-Language は希望、Content-Language は選ばれた内容、Vary は保存版を使い回す条件。三つを区別すれば、どの段階で本が取り違えられたか追える。

ブラウザーの設定が目の前の人を表すとも限らない。W3C の言語交渉ガイドは、借りたブラウザーに別人の好みが残っている例を示し、読者自身が版を変えられる見やすい操作を勧める。1997 年の RFC は、詳細な言語一覧を毎回送ることが私的な情報の開示にもつながると述べた。現行規格は、その一覧を利用者が制御できることを求める。

注文票、厨房、書庫、読者。HTTP はそれぞれに違う仕事を割り当てた。キャッシュが席札を残し、読者が自分の言葉で注文を直せれば、速さが親切になる。