web-dev-qa-db-ja.com

HTTP応答のキャッシュを回避する

HTTPデータのキャッシュを回避するための決定的なソリューションは何ですか？サーバーだけでなくクライアントも変更できます。したがって、クライアントとサーバーの間でタスクを分割できると思います。

クライアントは、各リクエストにランダムパラメータhttp://URL/path?rand=6372637263 –私は、この方法だけを使用しても100％動作しないと感じています。それを検出できるインテリジェントプロキシが存在する可能性があります。 単純に決定キャッシュされた応答を送り返すことはできません。

On serverは、多数のHTTPヘッダーを制御できます。

Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache

これに対するコメント、最良のアプローチは何ですか？

httpcachinghttp-headersclient-serverbrowser-cache
29
STeN

サーバー側のキャッシュ制御ヘッダーは次のようになります。

_Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: max-age=0, no-cache, must-revalidate, proxy-revalidate
_

キャッシュを汚染し、その他の奇妙なセマンティック問題を引き起こすため、クライアントでURLを書き換えないでください。さらに：

  • 複数のエントリの動作は未定義であるため、1つの_Cache-Control_ヘッダーを使用します（ rfc 2616 を参照）。また、2番目のcache-controlのMSIE固有のエントリは せいぜい冗長 です。

  • _no-store_はデータのセキュリティに関するものです。 （これはディスクにこれを書き込まないことを意味するだけです-キャッシュは応答をメモリに保存することを許可されています）。

  • _Pragma: no-cache_はサーバー応答では意味がありません-これは要求ヘッダーであり、要求を受信するキャッシュはそれをOriginに転送する必要があります。

  • Http/1.0のみを話すプロキシが存在するか、プロトコルをダウングレードするため、Expires (http/1.0)とcache-control (http/1.1)の両方を使用することは冗長ではありません。

  • 技術的には、最後に変更されたヘッダーは_no-cache_に照らして冗長ですが、そのままにしておくことをお勧めします。

  • 一部のブラウザーは、認識できないヘッダーに遭遇した後、キャッシュ制御ヘッダー内の後続のディレクティブを無視します。したがって、重要なものを最初に置いてください。

43
symcbean

ヘッダーを追加する

Cache-control: private

gatawayキャッシュがそのようなリクエストをキャッシュしないことを保証します。

キャッシュに関するFabien Potencierの講義をお勧めします。 http://www.slideshare.net/fabpot/caching-on-the-Edge

4
Jarosław Gomułka