ChromeでXmlHttpRequestのローカルキャッシュをバイパスするようにFirefoxで可能ですか？

Question

ご存知の方もいらっしゃるかもしれませんが、Firefox/ChromeにはXmlHttpRequestオブジェクトによって開始されるリクエストのキャッシュに関する問題がいくつかあります。これらの問題は、ブラウザが厳密にルールに従わず、新しいXSLTファイル（たとえば）のためにサーバーに移動しないことを意味します。レスポンスにExpiresヘッダーがありません（パフォーマンス上の理由から、使用できません）。

Firefoxには、XHRオブジェクトの "channel"に追加のパラメータがあり、これに値Components.interfaces.nsIRequest.LOAD_BYPASS_CACHEを指定すると、明示的にサーバーに移動します。

Chromeのようなものがありますか？

私は即座に誰も停止させてください。 GETパラメータまたはランダムな整数の値としてタイムスタンプを追加することをお勧めします。サーバが別のURL要求を受け取らないようにしたいと思います。元のURLを取得します。理由は、単純な静的ファイルの要求が多すぎてサーバーがクライアントに必要以上のデータを送信しないようにすることです。

生成されたGETパラメータ（ '？forcenew = 12314'など）を使用して静的ファイルをヒットした場合、最初に200回の応答が返され、ターゲットの静的ファイルがクライアントのバージョンと同一である場合、常に304を返す要求を出したいと思います。これは、どのようにWebブラウザがすぐに動作するのかはまだまだですが、XHRオブジェクトは、ファイルが変更されたかどうかを尋ねるためにサーバーにまったく移動しない傾向があります。

Answer 1

仕事中の私の主なプロジェクトでは、まったく同じ問題がありました。私の解決策は、ランダムな文字列やタイムスタンプをGET要求に追加するのではなく、という特定の文字列をGETリクエストに追加することでした。

リビジョン番号がある場合など。 Subversionのリビジョン、またはgit/merまたはあなたが使っているものと同じように、それを追加します。静的ファイルは新しいリビジョンがリリースされる瞬間までに304応答を得るでしょう。新しいリリースが発生した場合、単一の200応答が許可され、幸いに304応答を生成することに戻ります。 :-)

これには、ブラウザに依存しないという特典が追加されています。

リビジョン番号がないと不運になる場合は、リビジョン番号を付けないでください。

Answer 2

あなたはEtagsを見てください。etagsはファイルの内容から生成することができるキーなので、一度サーバーのファイルが変更されるとシステムは新しいetagになります。明らかに、これはサービス側の変更になります。これは、200以降の304を望む場合に必要なことです。 ChromeとFFはこれらのエタグを尊重する必要がありますので、クライマックスなクライアントサイドのハッキングを行う必要はありません。

Answer 3

現在、ChromeはCache-Control: max-age=0リクエストHTTPヘッダーをサポートしています。あなたがXMLHttpRequestインスタンスを開いた後、あなたはそれを設定することができます。

xhr.setRequestHeader("Cache-Control", "max-age=0"); 

これは、再検証せずにキャッシュされた応答を使用しないようにChromeを指示します。

詳細については、ノッティンガムのThe State of Browser Caching, RevisitedとRFC 7234 Hypertext Transfer Protocol (HTTP/1.1): Cachingのチェックを参照してください。