304 / If-modified-since / HEADリクエストを防ぐためのヘッダー

コンテンツがキャッシュされた後、サーバーへのすべてのリクエストを完全に停止するには、どのヘッダーを送信する必要がありますか？

非常に待ち時間の長いサーバー（Sigh、VMWare）があるためHEAD、サーバーへの要求の送信でも+ 40msかかります。

現在、これらは送受信されるヘッダーです。

最初のリクエスト

クライアントが送信します。

GET http://dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1
Host: dugong:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Pragma: no-cache, no-cache, no-cache
Cache-Control: no-cache, no-cache, no-cache

サーバーが応答します。

HTTP/1.1 200 OK
Server: nginx/1.0.11
Date: Wed, 01 Feb 2012 14:51:51 GMT
Content-Type: text/plain
Vary: Accept-Encoding
Last-Modified: Tue, 31 Jan 2012 10:45:11 GMT
Content-Length: 14
Expires: Thu, 31 Jan 2013 14:51:51 GMT
Cache-Control: max-age=31536000

だから、送信Cache-ControlしてExpires将来的には365日にヘッダセットを。残念ながら、2回目の更新では、If-Modified-Sinceヘッダーを使用してオブジェクトを再度要求します。

第二の要求

GET http://dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1
Host: dugong:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
If-Modified-Since: Tue, 31 Jan 2012 10:45:11 GMT
Cache-Control: max-age=0

応答;

HTTP/1.1 304 Not Modified
Server: nginx/1.0.11
Date: Wed, 01 Feb 2012 14:58:00 GMT
Vary: Accept-Encoding
Expires: Thu, 31 Jan 2013 14:58:00 GMT
Cache-Control: max-age=31536000

残念ながら、愚かな古いプロキシソフトウェアKeep-Aliveのため、アプリケーションの前に他のサーバー/ プロキシを使用することはできません。また、サーバーのパフォーマンスを向上させたり、ネットワークの待ち時間を短縮することもできません。301リクエストを取り除くために送信できるヘッダーを把握しようとしています。ETagsを使用してみましたが、違いはありませんIf-modified-since。ヘッダーを送信します。また、Last-Modifiedヘッダーを削除しようとしましたが、キャッシュなしで標準のGETリクエストが発生するだけです（ログを確認し、サーバーはまだリクエストを受信して​​います）。

クライアントは、Firefox（大部分）、IE 7、8、および（一部）9、Chrome、Safariが混在していますが、この動作はテストされたすべてのブラウザーで発生するようです。

TL; DR;

ひどいネットワーク、サーバーにリクエストを送信してキャッシュを検証し、ヘッダーが満たされるまでコンテンツをキャッシュし続けることをクライアントに伝えるために、どのヘッダーを送信する必要If-modified-sinceがありますExpiresか？

私はおそらく明らかな何かを見逃していますが、私が試みることはすべて同じ結果をもたらすようです。

_{アプリケーションサーバーの前にNGINXサーバーが配置されているため、必要に応じてヘッダーを追加/削除できます。私たちのプロキシはキープアライブをサポートしておらず、彼らのネットワークのパフォーマンスを向上させる方法はありません。ひどいソフトウェア設計により、Webアプリは、ページごとに+100のリソースをロードします（ええ、エンタープライズソフトウェアは最悪です）。}

ユーザーエージェントがあなたに送信することを決定するヘッダーを実際に制御することはできません。問題のファイルがブラウザのキャッシュ内にあり、新しいバージョンをチェックする必要があると判断した場合は、そうなります。この記事によると、これらはブラウザがIf-Modified-Sinceを使用して要求する状況です。

• キャッシュされたエントリには有効期限がなく、ブラウザセッションで初めてコンテンツにアクセスしています
• キャッシュされたエントリには有効期限がありますが、有効期限が切れています
• ユーザーが[更新]ボタンをクリックするか、F5キーを押してページの更新を要求しました

したがって、キャッシュをテストするためにページをリロードしている場合、ブラウザは画像を再要求するため機能しません。リンクをクリックしてから、最初のページに戻る別のリンクをクリックしてみてください。ユーザーが定期的にページをリロードしている場合、それを防ぐためにサイト/アプリの構造を再考する必要があるかもしれません。

役立つかもしれないことの1つは、キャッシュ制御ヘッダーに「パブリック」を追加することCache-Control: public, max-age=31536000です。私は最近、1年以上の有効期限が無効であることも知りました。有効期限は正確に1年であるため、おそらく数日または数週間短くすることで、ファイルがブラウザーのキャッシュに残り、破棄されないことが保証されます。

あなたが欲しいのはimmutableあなたのCache-Controlラインのキーワードです。phpの例：

header('Cache-Control: public, max-age=80000, immutable');

ソース：https : //code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook/

私は同じ問題を抱えていましたが、リクエストは間違いなくサーバーにヒットして304ステータスで応答します-私はいくつかのC＃を介して304を送信しており、確かにサーバーにヒットしています。

Cache-Control: private設定しただけです。いいえmax-age、いいえ、Expires期待どおりに動作しました。If-Modified-Since私が期待するものと比較して値をテストし、304空の応答本文を提供する場所でサーバーをヒットします-そうでなければ200、応答本文を完全にします。

Expiresヘッダーを設定すると200 - (from cache)、クライアントで目的の結果が得られ、サーバーにHTTPリクエストがヒットしませんでした。

しかし、..私はその設定を見つけBOTH max-age=＆Expiresブラウザが送信できないことがありますIf-Modified-Sinceヘッダーと、すべてのキャッシュにないと値が一致しない場合。

キャッシュに問題があり、さまざまなヘッダーを組み合わせて使用​​した場合に注意する必要があります。

少しオフトピックですが、役立つかもしれません。キャッシュされたコンテンツのリクエストのもう1つの改善点は、sessionStorageにキャッシュすることです。これにより、サーバーにキャッシュの検証と304の受信を要求する必要がなくなります。sessionStorageでCSSまたはDOMをキャッシュしていることがわかります。ofc、古いIEブラウザでは使用できません。

ソースコードを調べて、別のページに移行するためのメタリフレッシュがないことを確認します。代わりにsendRedirectなどを使用してください。私のセットアップでは、META REFRESHはIEで304を生成しますが、Chromeでは生成しません。sendRedirectは、どちらのブラウザーでもこれを生成しません。

<meta http-equiv="refresh" content="0;URL='nextpage'" />    

対

<% response.sendRedirect("nextpage") %>