ヘッダCache-Control: max-age=0
は、コンテンツがすぐに古くなっている(そして再フェッチされなければならない)と見なされることを意味します。これは事実上Cache-Control: no-cache
と同じことです。
最大年齢= 0
これは、 更新 をクリックするのと同じです。つまり、最新のコピーがある場合を除き、最新のコピーを入手してください。
キャッシュなし
これは、[更新]をクリックしているときに Shift を押したままにすることです。
今は昔の質問ですが、私が行ったように他の誰かが検索でこれに遭遇した場合、IE9はこれを利用して戻るボタンと進むボタンを使用する際のリソースの動作を設定するようです。 max-age = 0 が使用されている場合、前後の印刷機でリソースを表示するときにブラウザは最後のバージョンを使用します。 no-cache が使用されている場合、リソースは再取得されます。
IE9キャッシングについてのさらなる詳細はこの msdnキャッシングブログ投稿 で見ることができます。
私の最近のIE8とFirefox 3.5でのテストでは、どちらもRFCに準拠しているようです。ただし、それらはOriginサーバに対する「親しみやすさ」が異なります。 IE8は、no-cache
応答をmax-age=0,must-revalidate
と同じセマンティクスで扱います。しかし、Firefox 3.5では、no-cache
をno-store
と同等のものとして扱っているように見えます。これは、パフォーマンスと帯域幅の使用を嫌うものです。
Firefoxのように、Squid Cacheはデフォルトでno-cache
ヘッダを持つものを格納しないようです。
私のアドバイスは、リクエストごとに鮮度をチェックしたい、機密性の低いリソースにはpublic,max-age=0
を設定することですが、それでもキャッシングのパフォーマンスと帯域幅の利点は得られます。同じ考慮事項を持つユーザーごとのアイテムには、private,max-age=0
を使用します。
一部のブラウザや一般的なキャッシュによってno-cache
と同等の機能に規格化されているように思われるので、no-store
の使用は完全に避けます。
さらに、AkamaiとLimelightをエミュレートしないでください。彼らは本質的に彼らの主要なビジネスとして大規模なキャッシングアレイを運営していて、専門家であるべきですが、彼らは実際に彼らのネットワークからより多くのデータをダウンロードさせることに既得権を持っています。グーグルもエミュレーションには向いていないかもしれません。それらはリソースに応じてランダムにmax-age=0
またはno-cache
を使うようです。
max-age max-age = 0ディレクティブを使用して中間キャッシュが強制的に自身のキャッシュエントリを再検証するように強制され、クライアントが独自のキャッシュエントリを提供した場合リクエスト内のバリデータ、 で指定されたバリデータ、現在キャッシュエントリに格納されているバリデータとは異なる場合があります。 この場合、キャッシュは意味の透明性に影響を与えることなく、自身の要求を行う際にどちらかのバリデータを使用してもよい(MAY)。 ただし、バリデータの選択はパフォーマンスに影響を与える可能性があります。最善のアプローチは、 中間キャッシュがリクエストを行うときに独自のバリデータを使用することです。サーバが304(Not Modified)で と応答した場合、キャッシュは200(OK)応答で現在検証済みのコピーをクライアント に返すことができます。しかし、サーバが新しいエンティティとキャッシュバリデータで応答した場合 、中間キャッシュは強力な比較機能を使用して、返されたバリデータとクライアントの要求で提供されたバリデータを比較できます。クライアントのバリデータがオリジンサーバのバリデータと等しい場合、中間キャッシュは単に304(Not [.____。Modified])を返します。そうでなければ、200(OK)応答で新しいエンティティを返します。 リクエストにno-cacheディレクティブが含まれる場合、min-fresh、 max-stale、またはmax-ageを含めるべきではありません。
提供: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
答えとしてこれを受け入れないでください - 私はそれの本当の用法を理解するためにそれを読む必要があります:)
私はキャッシングの専門家ではありませんが、マーク・ノッティンガムはそうです。こちらが彼の キャッシュドキュメント です。彼はまた、参考文献セクションに優れたリンクを持っています。
それらのドキュメントの私の読書に基づいて、max-age=0
はキャッシュが「同じ時間」に到着したリクエストにキャッシュされた応答を送信できるように見えます。キャッシュしますが、no-cache
はキャッシュしません。
ちなみに、一部のモバイルデバイス、特にiPhone/iPadなどのApple製品は、キャッシュなし、ストアなし、Expires:0などのヘッダーを完全に無視します。フォームページ.
ユーザーのiPadの問題を解決しようとしたときに頭痛が起きることはありませんでした。フォームプロセスを経てページ上で眠ったままになっていました。 cacheディレクティブは、私が言うことができる限り、単に最後の状態からページの仮想スナップショットとは何か、つまり明示的に言われたことを無視すること、そしてそれだけではなく、保存すべきでないページを取ることですそして、それを実際に再度チェックすることなくそれを保存することは、とりわけあらゆる種類の奇妙なセッション問題につながります。
誰かがやってきて、特にiPhoneやiPadでセッションエラーが発生している理由がわからない場合は、これを追加するだけです。これは、この分野で最悪の犯罪者のようです。
私はこの問題についてかなり広範囲のデバッガテストをしました、そしてこれは私の結論です、装置はこれらの指令を完全に無視します。
通常の使用でも、一部の携帯電話では「Expires:0」などの方法で新しいバージョンをチェックできず、最後に更新された日付をチェックして新しいバージョンを入手する必要があるかどうかを判断します。
単純には起こらないので、更新を強制するために必要なcss/jsファイルにクエリ文字列を追加することを余儀なくされました。 css?v = 1であり、次いでcss / js更新に対してv = 2である。これは大体うまくいきます。
また、ユーザーのブラウザでも、2016年現在、デフォルトのままにしておくと(私たちが頻繁に変更やサイトの更新を行っています)、そのようなファイルの最終更新日をチェックできません。 stringメソッドはその問題を解決します。これは私がブラウザで基本的な一般ユーザのデフォルトを使いがちで、css/jsなどでキャッシュの問題を意識していないクライアントやオフィスの人々に気づいたことです。ほとんど常に新しいcss/jsを変更できません。つまり、ブラウザのデフォルト(主にMSIE/Firefox)は、指示されたとおりには動作しておらず、変更を無視し、最終更新日を無視し、Expires:0を明示的に設定しても検証しません。
これは多くの優れた技術情報を含む優れたスレッドでしたが、特にモバイル機器においてこのサポートがどれほど悪いのかに注目することも重要です。数ヶ月ごとに、受け取ったヘッダーコマンドに従わなかったり、それらのコマンドを適切に挿入したりしないようにするために、それらの失敗に対する保護層を追加する必要があります。
私はこれらのトピックを詳細にカバーする一連の記事を書いていますが、私見では明らかに開発者の間で十分に議論されていません。
ブラウザ、プライベートプロキシ、およびCDN:
https://medium.com/free-code-camp/http-caching-in-depth-part-1-a853c6af99db
Cache-Control
&Vary
https://medium.com/@lojacquemin/an-in-depth-introduction-to-http-caching-cache-control-vary-e3229815ddf4
違いは、no-cache(Firefoxではno-store)があらゆる種類のキャッシュを防止するということです。セキュリティで保護されたコンテンツを含むページがディスクに書き込まれないようにしたり、[戻る]ボタンを使用して再度アクセスされた場合でも常に更新されるべきページを防ぐために役立ちます。
max-age = 0は、キャッシュエントリが古くなっており、再検証が必要であるがキャッシュが妨げられていないことを示します。多くの場合、ブラウザはブラウザセッションごとに1回リソースを検証するため、新しいセッションでサイトにアクセスするまでコンテンツが更新されない可能性があります。
通常、ブラウザのキャッシュがいっぱいになったときに新しいコンテンツ用のスペースを取り戻していない限り、ブラウザは期限切れのキャッシュエントリを削除しません。 no-store、no-cacheを使用すると、キャッシュエントリを明示的に削除できます。