web-dev-qa-db-ja.com

Chrome Cache-Control：max-age？を無視しますか？

バックグラウンド：

  • IIS 7
  • AspNet 3.5 Webアプリ

Chrome開発ツールには、Webアプリのホームページ（aspx + js + css +画像）に対する98のリクエストが一覧表示されます。次のリクエストでは、ステータスコードは200 css/imagesファイル用。キャッシュ情報はありません。ファイルを更新する必要がある場合、ブラウザは毎回サーバーに問い合わせます。 OK。

IIS 7「ressources」フォルダーに6時間に設定されたキャッシュコントロールのHTTPヘッダーを設定します。Chromeでは、開発ツールを使用して、応答でヘッダーが適切に設定されていることがわかります。

Cache-Control: max-age=21600

しかし、私はまだ98件のリクエストを受け取っています...有効期限に達していない場合、ブラウザは1つのリソースをリクエストしてはならないと考え、リクエストの数が減ると予想していました...

iisgoogle-chromecache-controlcontent-expiration
36
Francois

わかった。 Google Chrome=は、同じタブ内の同じURIへの別のリクエストの直後にリクエストを行った場合、Cache-ControlまたはExpiresヘッダーを無視します（更新ボタンをクリックして、を押す F5 キーまたは押す Command + R）。おそらく、ユーザーが本当にしたいことを推測するアルゴリズムがあります。

Cache-Controlヘッダーをテストする方法は、それ自体へのリンクを含むHTMLドキュメントを返すことです。リンクをクリックすると、Chromeはキャッシュからドキュメントを提供します。たとえば、次のドキュメントに名前を付けますself.html：

<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Test Page</title>
</head>
<body>
    <p>
        <a href="self.html">Link to the same page.</a>
        If correctly cached, a request should not be made
        when clicking the link.
    </p>
</body>
</html>

別のオプションは、URLをコピーして同じタブまたは別のタブに貼り付けることです。

[〜＃〜] update [〜＃〜]： 2017年1月26日に公開されたChromeの投稿 では、 main resourceの再検証のみを行い、sub-resourcesの再検証を行わずに、以前の動作とその変化を説明しました。

ユーザーは通常、ページが壊れているか、コンテンツが古くなっているかのいずれかでリロードします。通常、既存のリロード動作は壊れたページを解決しますが、特にモバイルでは、古いコンテンツは通常のリロードによって非効率的に対処されます。この機能は元々、壊れたページが非常に一般的だった時代に設計されたため、両方のユースケースに一度に対処するのが妥当でした。ただし、Webページの品質が向上するにつれて、この当初の懸念は今ではあまり重要ではなくなりました。古いコンテンツのユースケースを改善するため、Chromeには、メインリソースのみを検証し、通常のページロードを続行する単純化されたリロード動作があります。この新しい動作により、キャッシュされたリソースレイテンシー、電力消費、データ使用量を削減します。

2017年1月26日に公開されたFacebookの投稿 では、 コードの一部 だったChromeはすべてのキャッシュを無効にするPOSTリクエストの後のリソース：

Chrome=は、POSTリクエスト。ロードされたページ上のすべてのリソースを再検証します。Chromeこの理由は、POSTリクエストは、購入やメールの送信などの変更を加えるページである傾向があり、ユーザーは最新の日付ページ。

これはもうそうではないようです。

最後に、Firefoxはリソースの再検証を完全に停止するためにCache-Control: immutableを導入していると説明されています。

Firefoxは、一部のリソースに新しいcache-controlヘッダーを追加して、このリソースを再検証してはならないことをブラウザに伝えるという、エンジニアの1人からの提案を実装しました。このヘッダーの背後にある考え方は、このリソースが最大有効期間中に変更されないという開発者からブラウザーへの追加の約束であるということです。 Firefoxは、このディレクティブをcache-control：immutable headerの形式で実装することを選択しました。

これがリロードの謎を解くのに役立つことを願っています。

68
kiewic

同じタブでリロードする場合、ChromeはCache-Control設定を無視しているようです。 URLを新しいタブにコピーしてそこに読み込むと、Chromeはキャッシュ制御タグを尊重し、キャッシュからコンテンツを再利用します。

例として、私はこれをRuby Sinatraアプリ：

#!/usr/bin/env Ruby

require 'sinatra'

before do
  content_type :txt
end

get '/' do
  headers "Cache-Control" => "public, must-revalidate, max-age=3600",
          "Expires" => Time.at(Time.now.to_i + (60 * 60)).to_s
  "This page rendered at #{Time.now}."
end

同じChromeタブで継続的にリロードすると、新しい時間が表示されます。

This page rendered at 2014-10-08 13:36:46 -0400.
This page rendered at 2014-10-08 13:36:48 -0400.

ヘッダーは次のようになりました。

< HTTP/1.1 200 OK
< Content-Type: text/plain;charset=utf-8
< Cache-Control: public, must-revalidate, max-age=3600
< Expires: 2014-10-08 13:36:46 -0400
< Content-Length: 48
< X-Content-Type-Options: nosniff
< Connection: keep-alive
* Server thin is not blacklisted
< Server: thin

ただし、複数の新しいタブから同じURL、http://localhost:4567/にアクセスすると、キャッシュから以前の結果がリサイクルされます。

14
slm

Chrome開発者ツールが開いている場合（F12）、Chromeは通常キャッシュを無効にします。

開発者ツールの設定で制御可能です-dev-toolsトップバーの右側にある歯車アイコン。

11
user3841754

この質問は古いものですが、httpsを介して自己署名証明書を使用して開発しており、証明書に問題がある場合、使用するキャッシュヘッダーに関係なく、Googleは応答をキャッシュしません。

これは、このバグレポートに記載されています。 https://bugs.chromium.org/p/chromium/issues/detail?id=110649

0
Beyerz