ブラウザキャッシュコントロール、動的コンテンツ

Question

問題： Dynamic Serverから送信された画像をキャッシュするためにFirefoxを取得できないようです

設定： BackEndの動的サーバー（mod_perl2）への逆プロキシを備えた静的Apacheサーバー。

サーバーのリクエストURLは次のとおりです。これは、Cookieが画像へのアクセスを検証するために使用される動的サーバーに送信されます。

ヘッダーをリクエストします

Host:  <OBSCURED>
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept:  image/png,image/*;q=0.8,*/*;q=0.5
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
Keep-Alive:  300
Connection:  keep-alive
Referer: <OBSCURED>
Cookie:  pz_cred=4KCNr0RM15%2FJCOt%2BEa6%2BL62z%2Fxvbp2xNQHY5pJw5d6Q
Pragma:  no-cache
Cache-Control: no-cache

動的サーバーは画像をサーバーに戻し、次の応答を提供します。

応答ヘッダー

Date:  Tue, 24 Nov 2009 04:28:07 GMT
Server:  Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
Cache-Control: public, max-age=31536000
Content-Length:  25496
Content-Type:  image/jpeg
Via: 1.1 127.0.1.1:8081
Keep-Alive:  timeout=15, max=75
Connection:  Keep-Alive

これまでのところ、とても良いです（私は考えています）。でも、 ページのリロードで, 、画像がキャッシュされていないように見え、リクエストが再び送信されます。

ヘッダーをリクエストします

Host: <OBSCURED>
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept:  image/png,image/*;q=0.8,*/*;q=0.5
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
Keep-Alive:  300
Connection:  keep-alive
Referer: <OBSCURED>
Cookie:  pz_cred=4KCNr0RM15%2FJCOt%2BEa6%2BL62z%2Fxvbp2xNQHY5pJw5d6Q
Cache-Control: max-age=0

ブラウザが画像をキャッシュする必要があるため、リクエストが発生するはずではないようです。現状では、最初の応答と同じ200の応答が受信され、画像が再びフェッチされているように見えます（ブラウザはキャッシュされた画像を使用しているように見えます）。

この問題は、上記のリロード要求ヘッダーのキャッシュ制御：最大時代= 0によって示唆されているように見えます。

なぜこれが起こっているのか誰もが知っていますか？おそらくそれはです 経由 問題を引き起こしている応答のヘッダー？

Answer 1

私の以前の答えは部分的に正しいだけでした。

問題 Firefox 3がイベントをリロードする方法です。どうやら、ほとんどの場合、Origin Serverからコンテンツを再度リクエストします。したがって Cache-Control: max-age=0 ヘッダーをリクエストします。

Firefox します キャッシュされた画像を使用してリロード上のページをレンダリングしますが、それでも「バックグラウンドで」それらを更新するすべてのリクエストが作成されます。その後、彼らが入ってきたらそれらを交換します。

したがって、ページは高速にレンダリングされ、YSLOWはキャッシュされたコンテンツを報告します。しかし、サーバーはまだ釘付けになっています。

解決策 Dynamic Serverスクリプトで着信ヘッダーを尋問し、「if-midified-since」ヘッダーが提供されているかどうかを判断することです。この場合、コンテンツが変更されていないと判断された場合、http_not_modified（304）応答が返されます。

これは最適ではありません - 私はむしろファイアフォックスが要求をまったく行わないことを望んでいます - しかし、それはページの読み込み時間を半分に削減し、帯域幅を大幅に削減します。 Firefoxがリロードで機能する方法を考えると、これは最良の解決策のように見えます。

他のコメント: ：ページから離れて戻ることについてのジムフェランのポイントにはメリットがあります。キャッシュは常に使用され、リクエストは発信されません（+1からジム）。また、動的に追加されたコンテンツ（初期負荷後のAjax呼び出し）もキャッシュを使用しているように見えます。

これが私以外の誰かを助けることを願っています:)

Answer 2

元のリクエストにはあります

Cache-Control: no-cache

これにより、すべての中間HTTPキャッシュ（Firefoxを含む）に、キャッシュされた応答を使用したくないことを伝え、Origin Webサーバー自体から応答を取得したいと考えています。

応答は次のように述べています

Cache-Control: public, max-age=31536000

これは、Origin Serverに関する限り、応答 五月 キャッシュされます。サーバーは、PNG画像をキャッシュできるように構成されているようです。 HTTP 1.1 （セクション14.21）は言う：

注：応答に、最大時代の指令を持つキャッシュコントロールフィールドが含まれている場合（セクション14.9.3を参照）、その指令は期限切れフィールドを無効にします。

2番目のリクエストには次のように書かれています。

Cache-Control: max-age=0

これにより、すべての中間HTTPキャッシュに、0秒以上古い応答を服用しないことがわかります。

注意すべきことの1つは、Firefoxでリロードボタンを押すと、Origin Webサーバーからリロードするように求めています。画像のキャッシュをテストするには、ページから離れてナビゲートするか、新しいタブで開きます。なぜノーキャッシュを初めて見たのか、最大年齢= 0を見たのかわからない。

ところで、私はFirefoxのFirebugプラグインが好きです。リクエストと応答ヘッダーを使用して、他のあらゆる種類の優れたものをご覧ください。

Answer 3

解決したように見えます：

• ヘッダーを介してプロキシを削除しました
• ラスト修飾ヘッダーを追加しました
• 遠くの期限切れの日付を追加しました

FireBugはまだOrigin Serverから200の応答を示していますが、Yslowは画像をキャッシュされたものとして認識しています。 YSLOWによると、フレッシュが500Kを超える場合の画像のダウンロードサイズの合計。キャッシュがプライミングされていると、0Kダウンロードサイズが表示されます。

これが、トリックを行うOrigin Serverからの応答ヘッダーです。

Date: Tue, 24 Nov 2009 08:54:24 GMT
Server: Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
Last-Modified: Sun, 22 Nov 2009 07:28:25 GMT
Expires: Tue, 30 Nov 2010 19:00:25 GMT
Content-Length: 10883
Content-Type: image/jpeg
Keep-Alive: timeout=15, max=89
Connection: Keep-Alive

画像をリクエストする方法のため、これらの日付が静的であるかどうかは本当に問題ではありません。私のアプリは、画像を要求する前の最後のmod時間を知っており、クライアント側のリクエストURLにこれを追加して、各画像バージョンの一意のURLを作成します。 http://myserver.com/img/125.jpg?20091122 （情報はAjax JSONフィードからのものです）。たとえば、2000年1月1日01日に最後の変更日を作成でき、2050年のいつかの期限は期限切れです。

YSLOWが正しい場合、そしてパフォーマンステストがそれを意味する場合、FireBugは200の応答ではなくこれらのローカルキャッシュヒットを実際に報告する必要があります。