Google Chromeも非同期GET(Ajax GET)がキャッシュされる(特定条件下で)

前回、Android1.6のブラウザで非同期GET/POSTがキャッシュされる、ということを書きました。

この際、PCのブラウザではどのような挙動になっているのか気になったので調べてみました。試したページは前回と同じこちら。

PCでのキャッシュロードは、一旦上記ページを開いた後、別のページに飛んで、その後

ブラウザの”戻る”ボタンで戻ってから再度実行しました。

色んなサイトでIEはXMLHttpRequestのGETがキャッシュされる、と書いてありましたが、IE8では仕様変更されたのでしょうか、特に他のブラウザと動作に差異はありませんでした。

一方、Google ChromeのGETは、前回示したAndroidのブラウザと同様、キャッシュロードの場合、GETのレスポンスにもキャッシュが用いられるようでした。ただし、Androidのブラウザと異なり、POSTは都度リクエストを行っているようです。

ついでにiPod touchのSafariでどうなるか試そうと思ったのですが、キャッシュロードされる条件がわかりませんでした…

下の表で、○はサーバにリクエストが行われた、×はリクエストが行われなかったことを表しています[追記：Firefox3.6.3でのアクセスログを見直したところ、Javascript ONの状態で「戻る」ボタンを押すと、ページ自体をサーバにリクエストし直していました。つまりiPod touch Safariと同様でしたので下の表では”?”表記に直しました]。

	サーバロード	キャッシュロード
IE8 GET	○	○
IE8 POST	○	○
Firefox3.6.3 GET	○	？
Firefox3.6.3 POST	○	？
Safari4.0.5 GET	○	○
Safari4.0.5 POST	○	○
Google Chrome 5.0.342.8 beta GET	○	×
Google Chrome 5.0.342.8 beta POST	○	○
Android1.6 Browser GET	○	×
Android1.6 Browser POST	○	×

Android Browserの挙動説明のついでに、上記ブラウザの挙動もキャプチャしてみました。7分25秒辺りからです。

RFC2616の9章によれば、GETもPOSTもある条件が揃えばキャッシュしても良いみたいですね。今回の件がその条件に当てはまっているのかは理解できていませんが。

あと、昔のSafari(1.3のころ)でもXMLHttpRequestのGETでキャッシュが用いられるという動作になっていたそうで、これの回避策としてリクエストヘッダのIf-Modified-Sinceに古い日付を指定する、というものがあったそうです。jQueryでの設定方法はこちらですね。

でも字面だけ見ると、modifiedなのかどうかって、サーバが判断すること(200(OK)なのか304(Not Modified)なのか)であってクライアントがリクエストするかどうかじゃ無いような気もしますが。今持ってるキャッシュは明らかに指定日付より新しいからリクエストしなきゃ、とかなんでしょうか。でも今持ってるキャッシュが古くても(というか古いからこそ)リクエストしないと分からないような気も。