35

サーバーからの応答を取得する代わりに、GET XMLHTTPRequest がブラウザーのキャッシュにヒットしたかどうかを (javascript の実行内で) 判断できる場合は?

4

6 に答える 6

23

XMLHttpRequest 仕様から:

ユーザー エージェントが生成した条件付き要求の結果である 304 Not Modified 応答の場合、ユーザー エージェントは、サーバーが適切な内容で 200 OK 応答を返したかのように動作する必要があります。

つまり、ブラウザのキャッシュにヒットしたリクエストに対しても、ブラウザは常にステータス コード 200 OK を返します。

ただし、仕様には次のようにも記載されています。

ユーザー エージェントは、オーサー リクエスト ヘッダーが自動キャッシュ検証 (If-None-Match または If-Modified-Since など) を上書きできるようにする必要があります。この場合、304 Not Modified 応答を渡す必要があります。

そのため、304 Not Modified 応答を JavaScript コードに表示するための回避策があります。

于 2013-05-29T15:16:49.867 に答える
3

ajaxリクエストを行うと、レスポンスコードを取得します

if (request.readyState == 4) {
     if (request.status == 200) { // this number.
       ...

ステータス 200 は、データの新しいコピーを取得していることを意味します。

リクエストは成功しました。応答で返される情報は、要求で使用されるメソッドに依存します -

ステータス 304 は、データが変更されていないことを意味し、ブラウザのキャッシュから取得します。

クライアントが条件付き GET リクエストを実行し、アクセスが許可されているが、ドキュメントが変更されていない場合、サーバーはこのステータス コードで応答する必要があります。

ステータス コードの詳細を読む

更新:
URL にキャッシュバスターを追加して、常にサーバーにヒットすることを保証できます。

var ajaxUrl = "/path?cache="+(Math.random()*1000000);
于 2012-12-09T00:55:21.417 に答える
1

この回答は、ブラウザのみのキャッシュを意味し、304 が発生していないという前提に基づいています (変更されたので、etag など)。

リクエストにかかった時間を確認します。リクエストがキャッシュから解決された場合は、0 ミリ秒近くかかるはずです。

于 2012-12-09T00:52:59.850 に答える
1

http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/から

ユーザー エージェントが生成した条件付き要求の結果である 304 Not Modified 応答の場合、ユーザー エージェントは、サーバーが適切な内容で 200 OK 応答を返したかのように動作する必要があります。ユーザー エージェントは、オーサー リクエスト ヘッダーが自動キャッシュ検証 (If-None-Match または If-Modified-Since など) をオーバーライドできるようにする必要があります。この場合、304 Not Modified 応答を渡す必要があります。[HTTP]

これはかなり曖昧だと思います。リソースが条件付きでリクエストされた場合、304 レスポンス コードが表示されると思いますしかし、別のコメント (ソース: https://developers.google.com/speed/docs/best-practices/caching ) で説明したように、そのリソースの最後の応答サーバーの http ヘッダーが設定Cache-Control: max-ageするかExpires、将来的に設定します。この場合、どうすればいいのかわかりません。

于 2012-12-09T01:47:30.793 に答える
0

FirefoxのFirebugを使用していますか?

Firebugには、「XHR」フィルタービューを備えた「ネット」パネルがあります。リクエストフェーズバーを介してキャッシュ情報を検査し、ステータスを確認したり、三角形をクリックして「ヘッダー」を検査したりできるはずです。

キャッシュされているかどうか

すべてのネットワークリクエストが同じというわけではありません。一部のリクエストは、ネットワークではなくブラウザのキャッシュから読み込まれます。Firebugはすべてのリクエストにステータスコードを提供するため、サイトがキャッシュをどの程度効果的に使用してページの読み込み時間を最適化しているかをすばやくスキャンして確認できます。

FirebugNetPanelのドキュメントはこちらです。

Chrome / Safari/Operaにはすべて同様のデバッグツールがあります。ここで良いリストを見つけました(ほとんどの場合、XHRを検査するためのツールが必要です)。


編集:

自分自身をいくらか償還するために...

ibuが答えたので、私も応答のステータスコードをチェックすることから始めます。

jQueryを使用している場合:

statusCode(1.5を追加) マップのデフォルト:{}応答に対応するコードがある場合に呼び出される数値HTTPコードと関数のマップ。たとえば、応答ステータスが404の場合、次のように警告します。

$.ajax({
  statusCode: {
    404: function() {
      alert("page not found");
    }
  }
});

リクエストが成功した場合、ステータスコード関数は成功コールバックと同じパラメータを取ります。エラーが発生した場合は、エラーコールバックと同じパラメータを使用します。

jQueryは確かに人生を楽にします。:)

于 2012-12-09T00:44:35.787 に答える