web-dev-qa-db-ja.com

Cache-Control：privateとは何ですか？

chesseng.herokuapp.com にアクセスすると、次のような応答ヘッダーが表示されます

Cache-Control:private
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/css
Date:Tue, 16 Oct 2012 06:37:53 GMT
Last-Modified:Tue, 16 Oct 2012 03:13:38 GMT
Status:200 OK
transfer-encoding:chunked
Vary:Accept-Encoding
X-Rack-Cache:miss

その後、ページを更新して取得します

Cache-Control:private
Connection:keep-alive
Date:Tue, 16 Oct 2012 06:20:49 GMT
Status:304 Not Modified
X-Rack-Cache:miss

キャッシュが機能しているようです。それがキャッシングのために機能する場合、ExpiresおよびCache-Control：max-age。混乱を招くため、 https://developers.google.com/speed/pagespeed/insights/ でページをテストすると、「ブラウザーのキャッシュを活用する」ように指示されます。

httpcachinghttp-headersbrowser-cachecache-control
136
user782220

Webサーバーにヘッダーが含まれていなくても、キャッシュが機能している理由に関する質問に答えるには：

  • 有効期限：[a date]
  • Cache-Control：max-age = [seconds]

サーバーは、コンテンツをキャッシュしないように中間プロキシを親切に要求しました（つまり、アイテムはprivateキャッシュにのみ、つまり自分のローカルマシンにのみキャッシュする必要があります）：

  • キャッシュ制御：private

しかし、サーバーはあらゆる種類のキャッシュヒントを含めるのを忘れていました。

  • Expiresを含めるのを忘れたため、ブラウザはその日付までキャッシュされたコピーを使用することを知っています
  • Max-Ageを含めるのを忘れていたため、ブラウザはキャッシュされたアイテムの有効期間を認識します
  • E-Tagを含めるのを忘れたため、ブラウザは条件付きリクエストを行うことができます

ただし、応答にはLast-Modified日付が含まれていました。

Last-Modified: Tue, 16 Oct 2012 03:13:38 GMT

ブラウザはファイルが変更された日付を知っているため、条件付きリクエストを実行できます。サーバーにファイルを要求しますが、2012/10/16 3:13:38以降にファイルが変更された場合にのみファイルを送信するようサーバーに指示します。

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

サーバーはリクエストを受信し、クライアントがすでに最新バージョンを持っていることを認識します。クライアント200 OKを送信してからページのコンテンツを送信するのではなく、キャッシュされたバージョンが適切であることを通知します。

304 Not Modified

ブラウザーは、サーバーへの要求の送信の遅延に悩まされ、応答を待つ必要がありましたが、静的コンテンツを再ダウンロードする必要はありませんでした。

なぜMax-Age？なぜExpires？

Last-Modifiedがひどいからです。

サーバー上のすべてのものに関連付けられた日付があるわけではありません。その場でページを構築している場合、それに関連付けられた日付はありません-それはnowです。しかし、私はユーザーに15秒間ホームページをキャッシュさせて完全に喜んでいます：

200 OK
Cache-Control: max-age=15

ユーザーがハンマーで打つ場合 F5、15秒間キャッシュバージョンを取得し続けます。企業プロキシの場合、同じ15秒のウィンドウで同じページにアクセスした67198人のユーザーはすべて同じコンテンツを取得します。すべてクローズキャッシュから提供されます。誰にとってもパフォーマンスの勝利。

Cache-Control: max-ageを追加する利点は、ブラウザーがconditional要求を実行する必要さえないことです。

  • Last-Modifiedのみを指定した場合、ブラウザーは要求If-Modified-Sinceを実行し、304 Not Modified応答を監視する必要があります
  • max-ageを指定した場合、ブラウザはネットワークの往復に悩まされることさえありません。コンテンツはキャッシュからすぐに出てきます

「Cache-Control：max-age」と「Expires」の違い

Expiresは、modern（c。1998）のCache-Control: max-ageヘッダーと同等のレガシーです：

  • Expires：日付を指定します（yuck）
  • max-age：秒を指定します（goodness）

  • また、bothが指定されている場合、ブラウザはmax-ageを使用します。

    200 OK
Cache-Control: max-age=60
Expires: 20180403T192837

1998年以降に作成されたWebサイトでは、Expiresを使用せず、代わりにmax-ageを使用する必要があります。

ETagとは何ですか？

ETagはLast-Modifiedに似ていますが、日付である必要があります-somethingである必要があります。

データベースから製品のリストを取得する場合、サーバーは日付ではなくETagとして最後のrowversionを送信できます。

200 OK
ETag: "247986"

ETagは、静的リソース（画像、js、css、フォントなど）、またはキャッシュされたレンダリングページのSHA1ハッシュ（つまり、これがMozilla MDN wikiの機能です。最終的なマークアップをハッシュします）：

200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

そして、Last-Modifiedに基づく条件付きリクエストの場合とまったく同じです：

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

304 Not Modified

ETagに基づいて条件付きリクエストを実行できます：

GET / HTTP/1.1
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

304 Not Modified

ETagは、files以外のもの、またはdateの概念を持つものに対して機能するため、Last-Modifiedよりも優れています。それはただis

47
Ian Boyd
Cache-Control: private

応答メッセージのすべてまたは一部が単一のユーザー向けであり、プロキシサーバーなどの共有キャッシュによってキャッシュされてはならないことを示します。

RFC2616セクション14.9.1 から

160
Dan D.

RFC 2616、 セクション14.9.1 ：

応答メッセージのすべてまたは一部が単一のユーザー向けであり、共有キャッシュによってキャッシュされてはならないことを示します...プライベート（非共有）キャッシュは応答をキャッシュできます。

ブラウザはこの情報を使用できます。もちろん、現在の「ユーザー」は、OSユーザー、ブラウザユーザー（Chromeのプロファイルなど）など、多くのことを意味する場合があります。指定されていません。

私にとって、Cache-Control: privateのより具体的な例は、プロキシサーバー（通常は多くのユーザーがいる）がキャッシュしないことです。これはエンドユーザー向けであり、他のユーザー向けではありません。

参考までに、RFCはこれがセキュリティを提供しないことを明確にしています。コンテンツを保護するのではなく、正しいコンテンツを表示することです。

このWordプライベートの使用は、応答がキャッシュされる場所を制御するだけであり、メッセージコンテンツのプライバシーを保証することはできません。

19
Paul Draper

Expires entity-headerフィールドは、応答が失効と見なされる日付/時刻を提供します。Cache-control：maxageフィールドは、応答が失効と見なされるよりも大きい経過時間値（秒単位）を提供します。

上記のヘッダーフィールドは、クライアントにリクエストをサーバーに送信するかどうかを決定するメカニズムを提供します。ある条件では、クライアントはサーバーにリクエストを送信し、応答の経過時間の値が最大値よりも大きい場合、サーバーがクライアントにリソースを送信する必要があることを意味しますか？たぶん、リソースは決して変わらなかったでしょう。

この問題を解決するために、HTTP1.1は最後に変更されたヘッドを提供します。サーバーはクライアントに応答の最終変更日を提供します。クライアントがこのリソースを必要とする場合、If-Modified-Sinceヘッドフィールドをサーバーに送信します。この日付がリソースの変更日より前の場合、サーバーはリソースをクライアントに送信し、200コードを送信します。それ以外の場合は、304コードをクライアントに返します。

0
Lin.Yang