「Vary：Accept」HTTPヘッダーの機能は何ですか？

PHPを使用して動的なWebページを生成しています。次のチュートリアル（下のリンクを参照）で述べられているように、X_HTMLドキュメントのMIMEタイプは、$ _ SERVER ['HTTP_ACCEPT']で許可されている場合、「application / xhtml + xml」である必要があります。2つの異なるMIME（「application / xhtml + xml」と「text / html」）で同じページを提供できるため、「Vary」HTTPヘッダーを「Accept」に設定する必要があります。これはプロキシのキャッシュに役立ちます。

リンク：http : //keystonewebsites.com/articles/mime_type.php

今、私は次の影響を確信していません：header（ 'Vary：Accept'）; 「Vary：Accept」が正確に何をするのか私は本当にわかりません...

私が見つけた唯一の説明は：

Content-Typeヘッダーの後、Varyヘッダーが送信され（私が正しく理解している場合）、プロキシサーバーなどの中間キャッシュに、ドキュメントを要求するクライアントの機能に応じてドキュメントのコンテンツタイプが異なることを伝えます。 http://www.456bereastreet.com/archive/200408/content_negotiation/

誰でも私にこのヘッダーの「本当の」説明を（その値で）与えることができます。私は次のようなことを理解していると思います：Vary：Accept-Encodingプロキシのキャッシュが提供されるページのエンコーディングに基づいている可能性がありますが、理解できません：Vary：Accept

• cache-controlヘッダは、キャッシングプロキシ応答の「鮮度」を指示するHTTPサーバの主要なメカニズムです。（つまり、キャッシュに応答を保存する方法/長さ）

• 一部の状況では、cache-controlディレクティブが不十分です。HTTPワーキンググループの議論はここにアーカイブされ、言語によってのみ変化するページについて説明しています。これは、varyヘッダーの正しい使用例ではありませんが、コンテキストは私たちの議論にとって価値があります。（この場合、Varyヘッダーで問題が解決されると思いますが、より良い方法があります。）そのページから：

Vary 厳密には、サーバーが行うことをプロキシーが複製することが絶望的または過度に複雑な場合に適しています。

• RFC2616 "Header-Field Definitions"は、サーバーの観点からのヘッダーの使用法、キャッシングプロキシの観点からのRFC2616 "Caching Negotiated Responses"について説明しています。リクエストの一意性を決定するHTTPリクエストヘッダーのセットを指定することを目的としています。

不自然な例：

HTTPサーバーに大きなランディングページがあります。ユーザーが以前にアクセスしたことがあるかどうかに応じて、同じURLのわずかに異なる2つのページがあります。Cookieに基づいて、リクエストとユーザーの「訪問数」を区別します。ただし、サーバーのランディングページが非常に大きいため、可能であれば中間プロキシが応答をキャッシュするようにします。

URL、Last-Modified、およびCache-Controlヘッダーは、キャッシングプロキシにこの洞察を与えるには不十分ですが、を追加するVary: Cookieと、キャッシュエンジンがCookieヘッダーをキャッシングの決定に追加します。

最後に、トラフィックが少ない動的なWebサイト-常にシンプルCache-Control: no-cache, no-storeでPragma: no-cache十分であることがわかりました。

編集-あなたの質問に正確に答えるために：HTTPリクエストヘッダー 'Accept'は、クライアントが処理できるContent-Typeを定義します。同じURLに同じコンテンツのコピーが2つあり、Content-Typeのみが異なる場合は、使用Vary: Acceptするのが適切です。

9月12日更新：

このコメントが最初に投稿されてから、コメントに表示されているリンクをいくつか含めています。これらはどちらも、Vary：Acceptの実際の例（および問題）の優れたリソースです。この回答を読んでいる場合は、それらのリンクも読む必要があります。

卓越したEricLawから、最初は、とのInternet Explorerの動作にヘッダと、それは開発者に提示課題のいくつかをヴァリ： IEでヘッダーを防ぎキャッシングヴァリ。つまり、IE（IE9より前）では、要求キャッシュにHTTP要求ヘッダーが含まれていないため、Varyヘッダーを使用するコンテンツはキャッシュされません。EricLaw（現実の世界ではエリックローレンス）は、IEチームのプログラムマネージャーです。

2つ目はEran Medanによるもので、ChromeでのVary関連の予期しない動作に関する継続的な議論です。バッキングはVaryヘッダーを正しく処理しません。これはIEの動作に関連していますが、Chrome開発者が異なるアプローチを取った点は異なりますが、意図的な選択ではなかったようです。

Vary: Accept単に、応答がAcceptリクエストのヘッダーに基づいて生成されたと言います。異なるAcceptヘッダーを持つリクエストは、異なる応答を受け取る場合があります。

（リンクされたPHPコードがを見ることがわかります$HTTP_ACCEPT。これがAccept要求ヘッダーの値です。）

これは、HTTPキャッシュにとって、応答は特に注意してキャッシュする必要があることを意味します。これは、まったく同じAcceptヘッダーを持つ後続のリクエストに対してのみ有効な一致になります。

これが問題になるのは、ページが最初からキャッシュ可能な場合だけです。デフォルトでは、PHPページはそうではありません。PHPページは、特定のヘッダー（Expiresなど）を送信することにより、出力をキャッシュ可能としてマークできます。しかし、それを行うかどうか、またその方法は別の問題です。

このグーグルウェブマスタービデオはHTTP Varyヘッダーについて非常に良い説明があります。

実際、Varyヘッダーが非常に便利になるかなりの数の新機能が近々（そしてすでにChromeに）登場します。たとえば、クライアントヒンティングを検討してください。たとえば、画像と組み合わせて使用​​すると、クライアントのヒンティングにより、サーバーは次の条件に応じて画像などのリソースを最適化できます。

• 画像の幅
• ビューポートの幅
• ブラウザでサポートされているエンコードのタイプ（WebPと考えてください）
• ダウンリンク（基本的にネットワーク速度）

したがって、これらの機能をサポートするサーバーは、 Varyヘッダーをを示します。

Chromeは、Vary各リクエストのヘッダーの一部として「image / webp」を設定することにより、WebPサポートをアドバタイズします。そのため、ブラウザがサポートしている場合、サーバーは画像をWebPとして書き換える可能性があるため、プロキシはWebP画像をキャッシュしないようにヘッダーを確認し、WebPをサポートしていないブラウザに提供する必要があります。明らかに、サーバーがそれをしなければ、それは重要ではありません。したがって、サーバーの応答はAcceptリクエストヘッダーによって異なるため、プロキシを混乱させないように、応答にそれを含める必要があります。

Vary: Accept

別の例は、画像の幅です。モバイルブラウザーではWidth、レスポンシブな画像のヘッダーは、デスクトップブラウザーから見た場合のヘッダーと比較してかなり小さい場合があります。したがって、その場合Width、Varyヘッダーにヘッダーを追加することは、プロキシが小さなモバイルバージョンをキャッシュせずにデスクトップブラウザーに提供しないために不可欠です。その場合、ヘッダーには以下が含まれます。

Vary: Accept, Width

または、サーバーがクライアントのヒント仕様のすべてをサポートしている場合、ヘッダーは次のようになります。

Vary: Accept, DPR, Width, Save-Data, Downlink