以前投稿した下記の話題の続編。
IIS 環境で、AngularJS の ng-include で読み込む HTML がキャッシュされたまま更新されない
http://devadjust.exblog.jp/22373190/
ブラウザーリンク機能が有効だと AngularJS の ng-include で読み込む HTML がキャッシュされたまま更新されない
http://devadjust.exblog.jp/22387945/
上記ブログ記事投稿時は失念していたが、もうひとつ、クライアント側での解決策もあったので、ここに補足しておく。
クライアント側での解決策
そのクライアント側での解決策だが、具体的には、
AngularJS から送信されるすべての XHR HTTP GET 要求 ― これには勿論 ng-include 関連の操作も含まれる ― に、
"If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT" 要求ヘッダを追加する、
というものである。
これは AngulraJS アプリケーションの初期の段階で、AngularJS の $httpProvider を構成することで実現できる。
具体的なコード例は
GitHub に公開してあるサンプルコードにて見ることができる。
こうしておけば以後は「手元にキャッシュがあるから要求送らないもんね」というブラウザの動作を抑止することになり、AngularJS からの XHR HTTP GET 要求が常にサーバーに送信されることとなる。
この点は以前にブログ記事に書いてある。
IE 上での AngularJS の XHR GET 要求にて、キャッシュが効きすぎる件
http://devadjust.exblog.jp/21257391/
以上の措置で、素の IIS の構成下、及び、Browser Link 機能の利用等の背景から ASP.NET の StaticFileHandler で静的 HTML をハンドルする構成下のいずれの場合でも、ng-include 対象がキャッシュされたままになる不具合が改善された。
警告: 但しお勧めはできません
なおこの方法だと、正規にキャッシュ制御できてて HTTP 304 Not Modified を返すだけで応答本体を省略できるようなシチュエーションであっても、クライアント側スクリプトで「"If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT"」ヘッダを強制していることから、サーバーは常に応答本体すべてを含んだ HTTP 200 OK 応答を返すこととなる。
しかも ng-include 関連に限らず、AngularJS ( というかその構成員である $http サービス) が行うすべての XHR HTTP GET 要求について、この影響を受ける。
このように処理速度上の問題があるため、クライアント側での解決策はお勧めはできかねる。
どうしてもサーバー側に手が出せないであるとか、一時しのぎ的に手早く問題をねじ伏せたい、などの特殊事情においてのみ、採用を検討するといいかもしれない手法である。