Webサービスのリリースで、最近iPhoneなどiOSデバイスだけ表示がおかしい、ということがあった。調べてみると、どうやらiOSデバイスでブラウザバックをしたときに、JavaScriptで前の値が残っていて、それに起因するエラーであった。
iOSデバイス以外では再現しなかったし、もっといえば開発環境でも生じない事象で、なかなか悩まされた。まぁこの事象が起きてしまったのは、ソースコードを見たところロジックに問題があったように思うのだが、それはそれとして、キャッシュの問題と環境依存の問題はまったくたいへんだ。。。
iOSだけの話
この問題が起きているのがiOSデバイスだけで、iOSだとSafariでもChromeでも同様の問題が起きるものの、AndroidデバイスやPCでは起きない、ということから、クライアント側の環境に依存する何かがあるのは間違いない。
調べていると、back-forward cacheことbfcacheの話が臭うね、という話になった（参考…「bfcache について覚えて帰ってもらいます。（転載） - oogatta のブログ http://oogatta.hatenadiary.jp/entry/20121228/1356696182」、「ブラウザキャッシュ(Cache Bustingとbfcache)について - Qiita」）。iOSデバイスだけ、bfcacheの扱いが他とずいぶん違うのではないのかなぁ、と。ありそうな話ではある。
サーバーサイドの話
が、話はそこで終わらなくて、今度は、そもそもこのキャッシュの再利用問題が、本番環境でだけ起きていて、開発環境では再現しないことがわかった。そうすると、クライアント側だけではなくサーバー側の環境も考えないといけない。
けれど、まぁ当たり前の話だが、本番環境と開発環境の違いは大きくはない。まぁ、元々開発環境にするつもりで作ったサーバーではなかったので、JavaやMySQLのマイナーバージョンの違いなどはたくさんあるのだけれど、あまりそこが原因とも思えない。キャッシュが関係するとなると、Webサーバーあたりを疑いたくなってしまうのだが、そこに設定の違いもないし。
などと考えていると、そういえば本番環境はちゃんとロードバランサをとおしてクライアントとhttpsでやりとりしているが、開発環境は直接http通信しているなぁと思い至る。となると、レスポンスヘッダはだいぶ異なりそうだ。上記の記事でも、cache-controlの設定でbfcacheの問題を回避したりなんだり、という話がされていたし。
と思って、Chromeで「chrome://net-export/」にアクセスして、クライアントでレスポンスヘッダの情報を調べてみたのだが、少なくとも受け取っているcache-controlに本番と開発で差異はない。しかしまぁ、ほかのところでなにかしら設定の違いはある気はする、するが、さて、どうなんだろう……。
ロジックの話
などと悩ましくあったのだが、そもそもソースコードのJavaScriptのロジックにも問題があるように思えるなぁ、ここをこうしたらキャッシュのこととか考えなくていいよなぁ、ということで、結局ロジックの変更で対応した。だから、原因の本当のところはわからずじまいなのだが、このキャッシュの問題というのは、うーん、実に、悩ましい…。
コメント