キャッシュを改善するために、Vary：ヘッダーとIf-none-match：を使用することは可能ですか？
ご存知のように、応答ヘッダーVary: Some-Headerを送信すると、リクエストで検出されるSome-Header:の各値に対応する、応答のさまざまなバリエーションをキャッシュに保存します（または、そうする必要があります）。ただし、この方法には、User-Agent:やAccept-Language:など、膨大なバリエーションを示すヘッダーがあるという欠点があります。
私たちのサーバーがそのような非常に可変的なヘッダーに基づいて変化したいが、実際にはほんの一握りのバリアントを提供したいとしましょう。私はフォローインほぼが機能すると思います：
- サーバーはすべての要求ヘッダーを使用して、提供するバリアントを決定します。バリアント＃42を送信することにしたと仮定しましょう
- サーバーは
Etag: variant42-version1およびVary: If-none-matchを送信します - このユーザーが次にページにアクセスするときに、おそらく
If-none-match: variant42-version1が追加されるため、キャッシュから取得しようとします。 - ただし、キャッシュにはそのようなエントリはありません。しかし、サーバーからの新しいクエリは、そのEtagで再び応答を引き起こし、将来のためにキャッシュされます
- 同じユーザーが3回目にページにアクセスする場合は、
If-none-match: variant42-version1を再度追加し、今回はキャッシュされたコンテンツを提供します
これに伴う問題は、Etagがまったくない最初のケースです。これらは、どのバージョンを提供するかについての複雑な評価を実行する必要がある初めての訪問者ですが、特にこれらの場合、If-none-match ...悪循環の代わりに元のヘッダーを変更する必要があります。
これを機能させることはできますか？ （または、キャッシュ可能なバリアントを削減するという望ましい効果を別の方法で達成できますか？）
質問と説明コメントに基づいて、ダウンストリームキャッシングサーバーを最適に処理するために、ヘッダーではなくURLを使用する方が適切です。言い換えると、初めて接続を取得するときに言語ヘッダーを確認し、URL（www.domain.com/en/またはwww.domain.com/deなど）を介して適切なコンテンツにリダイレクトします。これを行うことにより、サーバーをキャッシュするために特別なことをする必要がなくなります。さらに、一部のキャッシングサーバーは、ページのバリアントをサポートするように正しく構成されていないため、ヘッダーベースの言語変更を中断する可能性があります（ユーザーはドイツ語が必要ですが、英語バージョンはキャッシュされてキャッシングサーバーから返されます）。
Microsoftなどのインターネット上の最大規模のサイトでも、言語コードをURLに挿入して、ダウンストリームキャッシュサーバーの最適なサポートを確保しています。