web-dev-qa-db-ja.com

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

PHPを使用して動的Webページを生成します。次のチュートリアル（下記のリンクを参照）で説明されているように、XHTMLドキュメントのMIMEタイプは$ _SERVER ['の場合、 "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

httpcachingproxy
89
AlexV

  • cache-control ヘッダーは、HTTPサーバーがキャッシュプロキシに応答の「新鮮さ」を伝えるための主要なメカニズムです。 （つまり、応答をキャッシュに保存する方法/場合）

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

Vary は、サーバーが行うことをプロキシが複製することが絶望的または過度に複雑な場合にのみ使用されます。

不自然な例：

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が適切である可能性があります。

Update 12 Sep 12 ::

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

最初の傑出したEricLawから、Varyヘッダーを使用したInternet Explorerの動作と、開発者に提示するいくつかの課題について： Vary Header Prevents Caching Caching in IE 。つまり、IE（IE9以前）は、リクエストキャッシュにHTTPリクエストヘッダーが含まれていないため、Varyヘッダーを使用するコンテンツをキャッシュしません。EricLaw（実世界のエリックローレンス） IEチーム。

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

93
J.J.

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

（リンクされたPHPコードは$HTTP_ACCEPT。それがAcceptリクエストヘッダーの値です。）

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

これは、最初にページがキャッシュ可能である場合にのみ重要です。デフォルトでは、PHPページはありません。PHPページは、特定のヘッダー（Expires、 ）。しかし、それを行うかどうかとその方法は別の質問です。

55
Jason Orendorff

実際、Varyヘッダーを非常に役立つものにするかなりの数の新機能がすぐに（すでにChromeで）提供されています。たとえば、 Client Hinting を検討してください。たとえば、画像に関連して使用される場合、クライアントヒンティングにより、サーバーは次の条件に応じて画像などのリソースを最適化できます。

  • 画像の幅
  • ビューポート幅
  • ブラウザでサポートされているエンコードの種類（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
2
Brad Berger

この google webmaster video には、HTTP Varyヘッダーに関する非常に良い説明があります。

1
Kannan Mohan