IE11対応 - ユーザーエージェント文字列に"MSIE"が含まれなくなる件 - ASP.NET だけじゃなく PHP も

背景

Windows8.1から標準で付いてくる Internet Explorer(IE) 11。
このIEのバージョン11からは、ユーザーエージェント文字列が変更になり、"MSIE" の文字列が削除されることになった。

IEから送信されるユーザーエージェント文字列が、これまでは、

Mozilla/4.0 (compatible; MSIE 10.0; Windows NT 6.3; Trident/6.0)

みたいなのだったのが、

Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

というように、"MSIE" を含まない形式に変更されたわけだ。

もっとも、ASP.NET アプリケーションの開発者にとっては、この変更はさして影響がないはずである。

.NET Framework として提供されるブラウザ定義ファイルが正しく更新できていれば、HttpBrowserCapabilities オブジェクトを参照することで、"ブラウザの名前" ではなく、"そのブラウザに何ができるか" に基づいた判定が正しく行われる。

どうしても避けられないブラウザ互換問題に対処するにあたり、HttpBrowserCapabilities に基づいて判断する実装になっていれば、ユーザーエージェント文字列が変わったところで、痛くも痒くもない次第である。

理想と現実のギャップ

しかし現実にはなかなかそうはいかない。

古いコードの中には先に述べたような行儀の良い実装をしていないものがあるかもしれない。

すなわち、生のユーザーエージェント文字列に対して "MSIE" の文字列があるかどうかを検索してブラウザ種別を判定、振る舞いを変えている実装があったらどうなるだろうか。

そしてさらに、そのような実装が手元にソースがあって、修正とビルドが可能ならまだよい。

バイナリしかないサードパーティ製品であったり、修正がライセンスで禁じられていたりしたらお手上げである。

最後の手段 - ComeBackMSIEUserAgent

万が一、そのような窮地に追い詰められたときは、このモジュールを ASP.NET アプリケーションに投入してはいかがだろうか。

ComeBackMSIEUserAgent
https://github.com/jsakamoto/ComeBackMSIEUserAgent

このモジュールはすべての HTTP 要求を、要求処理の真っ先に傍受し、ユーザーエージェント文字列をチェックする。
そして、「ユーザーエージェント文字列に "MSIE" を含まないが "Trident" を含むので、IE11かそれ以降のブラウザによるアクセスである」と判定すると、ユーザーエージェント文字列を以下のような旧来形式に書き換えてしまう。

Mozilla/5.0 (compatible; MSIE 11.0; Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

こうすることで、ユーザーエージェント文字列に "MSIE" があるかどうかでブラウザが IE かどうかを判定しているようなレガシーなコードを救済するわけだ。

下図は今日現在における Windows Azure Websites にチェック用の ASP.NET Web アプリを立てて、IE11 でアクセスした実験の様子。
ComeBackMSIEUserAgent モジュールのインストール前は、Request.Browser.Browser が「Mozilla」になっているのがわかる。
※念のため補足しておくと、上図における「after」が正常という意味ではない。繰り返しになるが IE11 以降はブラウザの名前は「mozilla」でいい、という方向である。

インストール手順

ComeBackMSIEUserAgent のインストールは簡単で、対象となる ASP.NET Web アプリケーションプロジェクトを Visual Studio で開いたあと、NuGet パッケージ管理コンソールから以下のコマンドを入力すればよい。

PM> Install-Package ComeBackMSIEUserAgent

NuGet パッケージとしてでなく、手動でインストールする場合もさほど手間ではない。
ComeBackMSIEUserAgent.dll をこちらからダウンロードして bin フォルダに保存し、web.config を少しばかり書き換えればよい。
詳しくは GitHub リポジトリの README を参照。

PHP だって大丈夫!

ComeBackMSIEUserAgent モジュールの効果は、ASP.NET アプリケーションだけに限らない。

Windows Server OS における IIS7 以降の統合モード上で稼働しているのなら、PHP をはじめとした任意の処理系においても、ComeBackMSIEUserAgent によるユーザーエージェント文字列の書き換えが反映される。

「PHPには bin フォルダも web.config もないよ?」と思われるかも知れない。
だが、気にせずに bin フォルダを作成して ComeBackMSIEUserAgent.dll を保存し、web.config ファイルも新規に作成してルートに保存すればよいのである。

Windows Serevr の IIS は、ASP.NET と密接に統合されている。
そのため、PHP しか使ってないつもりでも、ASP.NET のパイプラインは動作していたのである。
なので、PHP による処理が始まる前段で、ComeBackMSIEUserAgent によるマジックが機能するのだ。

Windows Azure Websites などの Windows OS 上で WordPress を稼働させている場合などで、かつ、致し方ない理由からどうしてもサーバー側で IE の検出を行っているようなケースでは、一時的であるにせよ、ComeBackMSIEUserAgent を設置することで IE11 対策が済むかもしれない。(ただし未確認。)

下図は Windows Azure Websites 上に配置した phpinfo() な PHP ページに IE11 でアクセスした実験の様子。
ComeBackMSIEUserAgent モジュールをインストールすると、PHP にとっても、サーバー変数 HTTP_USER_AGENT が旧来形式に書き換わっているのがわかる。

注意とまとめ

ComeBackMSIEUserAgent はすべての要求を傍受している関係上、処理速度上の問題がありえる。

どうしてもユーザーエージェント文字列の書き換えというハックが必要な場合であっても、リバースプロクシなどアプリケーションサーバの前段があれば、それらリバースプロクシ側でユーザーエージェント文字列を書き換えるなどのほうが現実的かもしれない。

それでもなお、ComeBackMSIEUserAgent が役にたつ場面が少なからずあるかもしれない。
あくまでも一時的な救済措置とはいえ、参考になれば幸いである。