71

私の問題は、ブラウザーが一部のリソースを既に変更している場合でも、リソースを過剰にキャッシュすることがあるということです。しかし、F5以降はすべて問題ありません。

私はこの事件を午後中ずっと研究した。これで、「Last-Modified」または「Cache-Control」のポイントを完全に理解できました。そして、私は自分の問題を解決する方法を知っています(.js?version または明示的な max-age=xxxx のみ)。しかし、問題はまだ解決されていません。ブラウザーは、次のように「Cache-Control」なしで応答ヘッダーをどのように処理しますか?

Content-Length: 49675
Content-Type: text/html
Last-Modified: Thu, 27 Dec 2012 03:03:50 GMT
Accept-Ranges: bytes
Etag: "0af7fcbdee3cd1:972"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 24 Jan 2013 07:46:16 GMT

「バーに入る」ときにそれらを明確にキャッシュします

ここに画像の説明を入力

4

6 に答える 6

23

RFC 7234 では、ブラウザとプロキシがデフォルトで何をすべきかについて詳しく説明しています。

キャッシングは HTTP の完全にオプションの機能ですが、キャッシュされた応答を再利用することが望ましく、そのような再利用は、要件またはローカル構成がそれを妨げない場合のデフォルトの動作であると想定できます。したがって、HTTP キャッシュの要件は、キャッシュが常に特定の応答を格納して再利用することを義務付けるのではなく、キャッシュが再利用できない応答を格納したり、格納された応答を不適切に再利用したりしないようにすることに重点を置いています。

于 2016-06-14T15:55:43.100 に答える
20

通常、ブラウザではキャッシングがデフォルトで有効になっているため、cache-controlこの動作をカスタマイズするか無効にするために使用できます。

キャッシングは HTTP の完全にオプションの機能ですが、キャッシュされた応答を再利用することが望ましく、そのような再利用は、要件またはローカル構成がそれを妨げない場合のデフォルトの動作であると想定できます。したがって、HTTP キャッシュの要件は、キャッシュが常に特定の応答を格納して再利用することを義務付けるのではなく、キャッシュが再利用できない応答を格納したり、格納された応答を不適切に再利用したりしないようにすることに重点を置いています。[https://www.rfc-editor.org/rfc/rfc7234#section-2]

ブラウザーがキャッシュされた応答を最新と見なす時間は、通常、最後に変更された時間に関連しています。

オリジンサーバーは常に明示的な有効期限を提供するとは限らないため、明示的な時間が指定されていない場合、キャッシュはヒューリスティックな有効期限を割り当てることができ、他のヘッダーフィールド値 (Last-Modified 時間など) を使用するアルゴリズムを使用します... Last-Modified ヘッダー フィールド ([RFC7232] のセクション 2.2) があるため、キャッシュは、その時点からの間隔の一部にすぎないヒューリスティックな有効期限値を使用することが推奨されます。この割合の典型的な設定は 10% かもしれません。[https://www.rfc-editor.org/rfc/rfc7234#section-4.2.2]

この投稿には、さまざまなブラウザーがその値を計算する方法の詳細が記載されています。

于 2016-08-26T07:22:42.050 に答える
12

デフォルトのキャッシュ制御ヘッダーは次のとおりです: Private

キャッシュ メカニズムは、このページをプライベート キャッシュにキャッシュし、単一のクライアントにのみ再送信する場合があります。これがデフォルト値です。ほとんどのプロキシ サーバーは、この設定でページをキャッシュしません。

http://msdn.microsoft.com/en-us/library/ms524721%28v=vs.90%29.aspxを参照してください。

于 2013-01-24T09:19:46.790 に答える
0

キャッシュ制御ヘッダーがないと、ブラウザーは新しい (?) ページをロードするたびにリソースを要求します。F5 キーを押すと、そのページ内のキャッシュされたアイテムが無効化 (または論理的に削除) され、ローカル バージョンが利用できないため、完全なリロードが強制されます。ブラウザーがそれらのリソースを再度要求する前にキャッシュから削除するかどうかはわかりません。

おもしろいのは、一部のブラウザーには、ページの読み込みごとに 1 回だけリソースを要求するなどの最適化を引き起こす「追加の」設定がいくつかあることです。カウンターのようにリクエストごとに変化する画像がある場合、複数回使用しても、この画像の 1 つのバージョンしか表示されません。

次の 1 つは、ブラウザが nocache として明示的に設定されていない画像を、ある種のローカルの「優先」キャッシングを適用して再利用することです。毎回リクエストが必要な場合は、再検証するように設定し、期限切れを -1 などに設定する必要があります。

そのため、何も指定していないリソースによっては、仕様を読んで期待するものとは異なるデフォルトがトリガーされることがよくあります。

ソースがローカル、ドライブ、または実際に離れたインターネット サーバーのいずれに見えるかについても、異なる動作が発生する可能性があります。言うまでもなく、すべてのブラウザが異なる動作をしているわけではなく、私はかなり制限されています.

役立つのは、www.google.com を調べて、ページ リクエストのトラッキング ピクセルを探すことです (サブドメイン上のランダムな部分を持つ、metrics.gstats.com からリクエストされた 2 つの 1x1 ピクセル)。

firebug を使用してヘッダーをチェックアウトすると、可能な方法で nocache ディレクティブが指定されていることがわかります。ヘッダーは次のようになります。

Alternate-Protocol  443:quic
Cache-Control   no-cache, must-revalidate
Content-Length  35
Content-Type    image/gif
Date    Mon, 25 Nov 2013 14:33:30 GMT
Expires Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified   Tue, 14 Aug 2012 10:47:46 GMT
Pragma  no-cache
Server  sffe
X-Content-Type-Options  nosniff
X-Firefox-Spdy  3
X-XSS-Protection    1; mode=block

これを設定として試して、ブラウザが変更されたリソースを取得しないという問題が解決するかどうかを確認してください。must-revalidate ディレクティブにより、プロキシ キャッシュでさえ毎回リソースを要求し、304 Not Modified 応答をチェックします。

私は現在、似たようなことを経験しています。私は etag を設定する localhost 接続を持っています。キャッシュ情報などは設定していません。etag シームを指定するだけで、FireFox はリソースを再度要求しなくなります。だから私はあなたの問題に似た何かを経験します。

于 2013-11-25T21:21:13.203 に答える