問題タブ [if-modified-since]

サーバー上で画像が更新された場合、ページ上の画像を再読み込みしたい。他の質問では、次のようなことをすることが提案されています

画像を強制的に再読み込みしますが、実際には変更されていない場合でも再度ダウンロードされることを意味します。

If-Modified-Since実際に変更された場合にのみ画像がダウンロードされるように、適切なヘッダーを使用して同じ画像の新しい要求を生成する Javascript コードはありますか?

更新: 私はまだ混乱しています: 典型的な URL を要求すると、ローカルにキャッシュされたコピーが取得されます。（サーバーにキャッシュ不可としてマークを付けない限り、しかし、実際に変更しない限り再ダウンロードしないことが全体の考えであるため、そうしたくありません。）URLを変更すると、常に再新しい URL のポイントはキャッシュを壊すことなので、ダウンロードしてください。では、ローカルにキャッシュされたコピーと一致しない場合にのみファイルをダウンロードするなど、必要な中間動作を取得するにはどうすればよいでしょうか?

私のPHPスクリプトは、ヘッダーの値を読み取れるかどうかに依存していますIf-Modified-Since（はい、これを行う方法を知っています）。

PHPをmod_phpとして使用した場合は正しく機能しましたが、suPHP（CGI）に切り替えたため、Apache自体がこのヘッダーを含むリクエストをPHPに転送せずに処理しているようです。

これはばかげています。なぜなら、動的に生成されたCSSファイル（スクリプトが作成するもの）がいつ変更されたかをApacheが認識できない可能性があるからです。この点でApacheをどのように訓練できますか？

PHP で生成されたコンテンツの If-Modified-Since ヘッダーがブラウザから返されない

私のスクリプトが送信する最初のリクエストで：

送信する2番目のリクエストで：

サーバーが最初に送信する他のファイルの場合:

私のブラウザは、次のリクエストで次を送信します。

If-Modified-Since ヘッダーを送信する理由

HTTPヘッダーを使用して条件付きリクエストを実装するには、2つの異なる方法があるようです。どちらもキャッシング、範囲リクエスト、同時実行制御などに使用できます...:

1. クライアントがリソースのタイムスタンプを送信するIf-Unmodified-Since および If-Modified-Since 。
2. If-Modified および If-None-Modified 。クラ​​イアントはリソースのETag表現を送信します。

どちらの場合も、クライアントはリソースに関する情報を送信します。これにより、クライアントがリソースを最後に参照してからリソースが変更されたかどうかをサーバーが判断できるようになります。次に、サーバーは、クライアントから提供された条件付きヘッダーに応じて、要求を実行するかどうかを決定します。

なぜ2つの別々のアプローチが利用できるのかわかりません。確かに、サーバーはタイムスタンプから ETag を生成することを非常に簡単に選択できるため、ETag はタイムスタンプに取って代わります。

だから、私の質問は次のとおりです。

• ETag よりも If-Unmodified-Since/If-Modified-Since を好むシナリオはどれですか?
• どのシナリオで両方が必要になる可能性がありますか?

HttpWebRequest を使用してアクセスしようとした一部のリンクで、「リモート サーバーがエラーを返しました: (304) 変更されていません」というメッセージが表示される理由を教えてください。コードで？

私が使用しているコードは、こちらの Jeff の投稿からのものです(ページは消えてしまったようです。Wayback Machine のアーカイブ コピーを参照してください)。

コードの概念は単純なプロキシ サーバーであることに注意してください。そのため、ローカルで実行されているこのコード部分をブラウザーに向けて、ブラウザーの要求を取得し、新しい HttpWebRequest を作成してプロキシします。コード。ほとんどのサイト/リンクで問題なく機能しますが、一部のサイトではこのエラーが発生します。コードの重要な部分の 1 つは、http ヘッダー設定をブラウザー リクエストからサイトへのリクエストにコピーしているように見え、ヘッダー属性をコピーするところです。問題がリクエストのこの側面をどのように模倣するかに関係しているかどうかわからない場合、結果が戻ってくるとどうなりますか?

たとえば、http://en.wikipedia.org/wiki/Main_Pageから問題を取得します

PS。ここで更新

これはまだ解決できません。基本的に、問題のある 1 つのリンクを特定でき、正常に動作しているように見えます。2 回目はエラーが発生し、3 回目は OK、4 回目はエラーが発生し、5 回目は OK などです。クリアされていない状態があるかのように、またはコードの何か。「using」型ステートメントなどを使用して、コードを少しクリーンアップしようとしました。

これがコードです。http://newsimg.bbc.co.uk/css/screen/1_0_16/nol/v4/story.cssのようなリンクを2回目にブラウズする理由を誰かが見つけられる場合（最初ではなく2回目から）このプロキシ コードを介して、聞きたいエラーが表示されます。

そして、これが私が見たものの例です-最初のヒットは良好で、2番目にはエラーがあります...

仕様を理解している限り、RFC 2616（HTTP / 1.1）で導入されたETagは、Last-Modified-Headerの後継であり、ソフトウェアアーキテクトにキャッシュ再検証プロセス。

RFC 2616によると、Cache-Validation-Headers（If-None-MatchとIf-Modified-Since）の両方が存在する場合、リソースが変更されているかどうかを確認するときに、クライアント（つまりブラウザー）はETagを使用する必要があります。RFC 2616のセクション14.26によると、If-None-Match-Headerに表示されるETagが変更され、サーバーが追加のIf-Modified-Since-Headerを無視する必要がある場合、サーバーは304NotModifiedで応答してはなりません。 、 存在する場合。提示されたETagが一致する場合、Last-Modified-Headerの日付で指定されていない限り、リクエストを実行してはなりません（MUSTNOT）。（提示されたETagが一致する場合、サーバーはGETまたはHEAD要求の場合に304 Not Modifiedで応答する必要があります...）

このセクションには、いくつかの推測の余地があります。

• 強力なETagは「毎回」変更されることになっており、リソースが変更されます。したがって、変更されていないETagとIf-Modified-Since-Headerを使用したリクエストに対して、304 Not Modifiedとして応答する必要がありますが、これは少し矛盾しています。これは、強力なETagがリソースが変更されていません。（ただし、サーバーは同じ変更されていないリソースを再度送信できるため、これはそれほど致命的ではありません。）
• ..。

... ok私がこれを書いている間、質問はこの答えに沸騰していました：

上記の（小さな）矛盾は、ETagが弱いために発生しました。弱いETagでマークされたリソースは変更されている可能性がありますが、ETagは変更されていません。したがって、弱いETagの場合、ETagが変更されていないのに、304 Not Modifiedで応答するのは間違っていますが、If-Modified-Sinceに表示される日付が一致しません。

基本的なログイン/ログアウト システムを備えたサイトを持っています。

ページを表示するときは、ページが最後に変更されたのはいつか、ブラウザーが if modified since ヘッダーを送信したかどうかを確認します。変更されていない場合は304、ヘッダーを送信して終了します。

これにより、ページの読み込みが明らかに速くなり、ページのコンテンツを構築する必要がないため、メモリと処理能力が少なくなります。

ただし、ユーザーがログインして変更されていないページを表示すると、「サインイン」ボタンが表示されます。ログアウトして変更されていないページを表示すると、オプションが表示されます。にlogout。

304これは、変更されていないヘッダーを使用したい人にとってはよくあることのようですが、解決方法についての議論を見つけるのに苦労しています。

どんな助けでも大歓迎です（私は多くの情報を提供していないことに気づきましたが、他に何を言うべきかわかりません。それは非常に自明です）

キャッシュできることがわかっている高価な WebRequest があります。

Last-Modified/If-Modified-Since および (オプションで) ETag に基づいて Web 要求をキャッシュできる既存のソリューションはありますか?

小さな画像（アイコン）がたくさんあるページがあります。chromeで使用すると、ページがリロードされるたびに、chromeはif-modified-sinceヘッダーを使用してサーバーに各アイコンを要求します。

すべてのアイコンには、expiresヘッダーとmax-ageヘッダーが付いています。Firefoxはキャッシュから画像をロードします。

なぜクロムがそれをしているのですか、そしてどうすればそれを防ぐことができますか？

ありがとう

ファイル拡張子のみが異なる同一のファイルを PHP エンジンが処理する方法には問題があるようです。

問題: 「If-Modified-Since 条件付きリクエストが完全なコンテンツを変更せずに返しました。」

また、ファイルの内容が同一であり、ファイル拡張子のみが異なる場合でも、.php 拡張子は .xxx 拡張子を持つ同一のツインよりもはるかに高速に読み込まれることが測定されました。

「HTTP により、クライアントは保持しているコピーがまだ有効かどうかを確認するための条件付き要求を行うことができます。この応答には Last-Modified ヘッダーがあるため、クライアントは検証のために If-Modified-Since 要求ヘッダーを使用できるはずです。RED は完了しました。これにより、リソースが変更されていないにもかかわらず、リソースが完全な応答を送信することがわかりました。これは、Last-Modified 検証をサポートしていないことを示しています。」

で終わるホームページ.php

まったく同じファイルですが、終了します.ast

与えられた:

home.php ファイルは、home.xxx としてコピーされ、この拡張子が htaccess に追加され、PHP ファイルとして認識されます。.php ファイルは、鮮度が 3 時間に設定されている php.ini をリッスンし、非 .php ファイルは、鮮度が 2 時間に設定されている htaccess をリッスンする必要があります。

より具体的には、php 以外のファイルが適切にキャッシュされないか、適切にキャッシュされるが適切に検証されないことを除いて、これまでのところうまくいき、すべてが読み込まれます。同封の画像を参照してください。PHP 以外のファイル拡張子のみがエラーを引き起こし、読み込みが遅くなります。

page.php 全体は、そこにあるすべての要素がキャッシュから適切に読み込まれるため、高速に読み込まれますが、page.abc はキャッシュされるべきであるにもかかわらず完全なリクエストが返されるため、ページ全体が遅くなります。

結論: コンテンツ全体を変更せずに返す If-Modified-Since 条件付きリクエストをなくすには、何を変更する必要がありますか?