IE上でのAngularJSのXHR要求にてキャッシュが効きすぎる件 - ASP.NET WebAPIでキャッシュ禁止を明示する

前回の投稿「IE 上での AngularJS の XHR GET 要求にて、キャッシュが効きすぎる件」について、しばやん先生から、「サーバー側でキャッシュ制御を明示したら?」との示唆をもらったので、補足を。

あいにくと Google Chrome 及び Firefox と比べて、「キャッシュが効きすぎる」とした IE であるが、この「効きすぎ」はあながち "間違い" とはいえない。

実際、例えば Google Map のように、いちど取得した地図画像は、次回の XHR 要求においても、もしブラウザ側にキャッシュが残っていれば、いちいちサーバーに問い合わせせずにそのキャッシュをそのまま使った方がいいに決まっている。

このように「同じ URL であれば、何度 XHR 要求を送っても同じ応答が返る」ことが仕様として明らかなケースも少なからずあるだろう。

そういう点から、IE の「キャッシュ効きすぎ」は間違いとは言えない。
IE と ChromeまたはFirefoxと比べての、「キャッシュ効く/効かない」の違いは、（詳しくはないので予想・私見であるが）ブラウザ実装における設計思想の違いなのかもしれない。

根本的な問題はどこにあるか

実はこのような「キャッシュが効く/効かない」の本質的な解決策はサーバー側実装にある。

XHR 要求に対してサーバー側から返す応答ヘッダにキャッシュ制御が無い場合、ブラウザは、その XHR 要求に対する応答をキャッシュしていいものかどうか、明確には判断つかないことになる。
これがブラウザ間でキャッシュに関する振る舞いが一貫しないことについての元凶だろう。

応答ヘッダにキャッシュ制御がちゃんと記されていれば、

• その応答をキャッシュして次回はサーバーに要求送らなくても大丈夫なものなのか、
• それとも動的なコンテンツであって毎回サーバーにちゃんと要求送るべきものなのか、

判断できるようになる。

ASP.NET WebAPI を使用したサーバー側実装では、何も指定がない既定の状態だと、キャッシュ制御に関する応答ヘッダを一切付けずに応答を返している。
このため、IE とそれ以外のブラウザとで、振る舞いの違いが露見してしまう次第。

ASP.NET Web API で、明示的にクライアント側キャッシュを禁じるには

ASP.NET WebAPI を使用したサーバー側実装で、クライアント側キャッシュを禁じるには、以下の手順で実装可能だ。

まず、NuGet パッケージ「Strathweb.CacheOutput.WebApi2」をインストールする。

PM> Install-Package Strathweb.CacheOutput.WebApi2

次に、API コントローラーの各アクションメソッドに、「CacheOutput」属性を付与して、そこでキャッシュ制御構成を記述すればよい。
クライアント側キャッシュを単純に禁じるには、NoCacheプロパティに true を指定すればよかろう。

using WebApi.OutputCache.V2;

...

public class ValuesController : ApiController

{

    [CacheOutput(NoCache = true)]

    public int[] Get()

    {

        ...

以上の措置を行えば、前回投稿で示したような、クライアント側実装にて全 XHR 要求に「If-modified-Since」ヘッダを指定する仕掛けは実は不要だ。

まとめ

よくよく考えるに、上記のとおりサーバー側でこまめにキャッシュ制御を明示すれば、「同じURLなら応答内容は変わらない」リソースについてはキャッシュが効くようになり、より処理性能が良くなる気がする。

もちろん、サーバー側実装に手が出せないケース（CORSな外部サイトの API を呼ぶ場合など）もあるだろうし、規模が小さいアプリだと、むしろサーバー側実装は質素に抑えて、XHR キャッシュを全面無効にしたほうが手早いケースもあるだろう。

そのようなケースでは、依然、前回投稿のような「If-Modified-Since」ヘッダ追加の技法が有効ではある。

だがしかし、サーバー側実装にてキャッシュ制御を明示できるのなら、そのような解決策をじゅうぶん検討したほうがよさそうだ。