WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

IIS Express と gzip 圧縮

by WebSurfer 24. April 2017 23:38

Visual Studio 2015 で ASP.NET Web アプリを開発する際に使用される IIS Express はデフォルトで gzip 圧縮された応答を返すように設定されるという話を書きます。

注:Visual Studio 2015 Community Update 3 のテンプレートを使ってデフォルト設定で生成する ASP.NET Web アプリのプロジェクトの話です。Visual Studio Community 2019 の場合、使用する applicationhost.config には <httpCompression /> となっており、圧縮されません。VS2017 の場合は不明です。

Fiddler によるキャプチャ結果

Visual Studio 2010ではデフォルトで ASP.NET 開発サーバーを使用します。IIS Express も、先の記事「IIS Express をインストールしました」に書きましたように、別途ダウンロードしてインストールすれば使用可能です。

しかしながら、Visual Studio 2015 では ASP.NET 開発サーバーを使用できませんので、IIS Express またはローカル IIS のいずれかを使うことになります。

当然ながらローカル IIS より IIS Express の方が手軽かつ便利ですし、以下の理由もあって、少なくとも開発の初期には IIS Express を使わざるを得ません。

  1. EF Code First + LocalDB の機能を使ってユーザー情報のストア(.mdf ファイル)を App_Data フォルダに生成するというところがローカル IIS ではできません。
  2. LocalDB を動かすにはユーザープロファイルが必要なので IIS Express を使わざるを得ません。(詳しくは MSDN Blog の記事「Using LocalDB with Full IIS, Part 1: User Profile」を見てください。その記事の Part 2「Using LocalDB with Full IIS, Part 2: Instance Ownership」に書いてあるような解決方法はあるそうですが、個人的には無理に LocalDB を使うより SQL Server Express を使った方がよさそうだと思います)

ローカル IIS を使うには、IIS 上でのアプリケーションの設定とフォルダの権限の設定はもちろん、EF Code First + LocalDB の機能で App_Data フォルダに生成された .mdf ファイルをコピーして SQL Server にアタッチし、Web アプリから SQL Server に接続できるようにするという設定の変更が必要になります。

ということで、Visual Studio 2015 を使っての ASP.NET Web アプリの開発には、自分もやむを得ず(?)ほとんど使ったことがない IIS Express を使い始めました。

ところが IIS Express とローカル IIS ではデフォルトの設定が違っているようで、まず気が付いたのが gzip 圧縮です。

IIS で静的コンテンツの圧縮をかけるにには、MSDN Blog の記事「IIS7 以降の静的コンテンツの圧縮について」によると、役割サービスで [静的コンテンツの圧縮] を有効にするなどの設定が必要とのことです。

ローカル IIS にはそのような設定はしてないので gzip 圧縮はかかりません。ところが、IIS Express ではデフォルトで gzip 圧縮がかかります。上の画像を見てください。

IIS Express の ApplicationHost.config を調べてみると以下の設定がありました。これの、<dynamicTypes> から </staticTypes> までをコメントアウトすると gzip 圧縮はかからなくなります。(注:ファイルがどこにあるかは先の記事「ApplicationHost.config の場所」を見てください)

<httpCompression 
  directory="%TEMP%\iisexpress\IIS Temporary Compressed Files">
  <scheme name="gzip" dll="%IIS_BIN%\gzip.dll" />
  <dynamicTypes>
    <add mimeType="text/*" enabled="true" />
    <add mimeType="message/*" enabled="true" />
    <add mimeType="application/javascript" enabled="true" />
    <add mimeType="application/atom+xml" enabled="true" />
    <add mimeType="application/xaml+xml" enabled="true" />
    <add mimeType="*/*" enabled="false" />
  </dynamicTypes>
  <staticTypes>
    <add mimeType="text/*" enabled="true" />
    <add mimeType="message/*" enabled="true" />
    <add mimeType="image/svg+xml" enabled="true" />
    <add mimeType="application/javascript" enabled="true" />
    <add mimeType="application/atom+xml" enabled="true" />
    <add mimeType="application/xaml+xml" enabled="true" />
    <add mimeType="*/*" enabled="false" />
  </staticTypes>
</httpCompression>

まだ調べてませんけど、gzip 圧縮以外にも違うところがありそうです。重大な違いに気が付いたら別途記事を書くつもりです。

Tags: ,

DevelopmentTools

URL Rewrite Module の Outbound Rules

by WebSurfer 20. March 2017 16:56

gzip 圧縮済みのコンテンツを応答としてブラウザに返す場合、下の画像のように応答ヘッダに Content-Encoding: gzip を設定する必要があります。

応答ヘッダ

HTTP ハンドラを使って自分でダウンロードするコードを書く場合は自由に応答ヘッダを追加できますが、IIS の静的ハンドラを使う場合(例えば、img 要素の src 属性に .svgz 画像のパスを設定したような場合)はどうすればいいでしょう?

URL Rewrite Module 2.0 の Outbound Rules を利用すると応答ヘッダに Content-Encoding: gzip を設定できます。.svgz 画像の場合を例にとって以下にその方法を書きます。(注: Content-Type: image/svg+xml も必要ですが applicationHost.config の MIME Map で設定済みであれば何もする必要はありません。IIS Manager で調べてください)

URL Rewrite Module の Outbound Rules

IIS Manager を起動して、上の画像のように Add Rule(s) ダイアログで Outbound Rules の Blank rules を選択し、OK ボタンをクリックすると Edit Outbound Rule という編集画面が開くので、そこでまず Precondition を定義します。

Precondition の定義

上の画像は Precondition の名前を IsSVGZ とし(任意)、Server Variable の URL(クエリ文字列等を含まないベースの部分)が正規表現の \.svgz$ にマッチする(.svgz で終わる)という条件になっています。URL の代わりに PATH_INFO を使っている記事がありますが、 ASP.NET の場合はどちらも同じ結果になりますので、分かりやすいと思われる URL を使用しました。

Precondition 設定後 Edit Outbound Rule 編集画面に戻って、Rule 名(任意)と Match 条件を設定します。下の画像の赤枠で囲った部分を見てください。

Name と Match の設定

Server Variable 名の RESPONSE_CONTENT_ENCODING と言うのは、Microsoft の公式文書には見つかりませんでしたが、応答ヘッダの Content-Encoding になるようです。正規表現の .* は 0 個以上の任意の文字という意味です。

ちなみに、RESPONSE_ が頭に付いている Server Variables には、RESPONSE_CONTENT_ENCODING 以外に、以下の画像の項目があるようです。未検証未確認ですが、それらは全て URL Rewrite Module で書き換え可能かもしれません。

Action の設定

次に Edit Outbound Rule 編集画面の下の方にある Action の設定を行います。下の画像の赤枠で囲った部分を見てください。

Action の設定

上記の操作の結果、当該サイトの web.config に以下のコードが生成されます。(逆に言えば、IIS Manager を操作しなくても、web.config を編集して以下のコードを追加しても同じ結果が得られます)

 
<system.webServer>
  <rewrite>
    <outboundRules>
      <rule name="Rewrite SVGZ header" 
        preCondition="IsSVGZ" stopProcessing="true">
        <match serverVariable="RESPONSE_CONTENT_ENCODING" 
          pattern=".*" />
        <action type="Rewrite" value="gzip" />
      </rule>
      <preConditions>
        <preCondition name="IsSVGZ">
          <add input="{URL}" pattern="\.svgz$" />
        </preCondition>
      </preConditions>
    </outboundRules>
  </rewrite>
</system.webServer>

上の web.config の設定により、Server Variable の URL が .svgz で終わっている要求に対しては、応答ヘッダの Content-Encoding を gzip に書き換える(無ければ追加する)という操作が URL Rewrite Module によって行われ、一番上の画像で示したように Content-Encoding: gzip が付与されます。

<注意>

URL Rewrite Module は自分でダウンロードしてインストールする必要があります。インストールしてないと web.config を書き換えても効果はありません。

Microsoft URL Rewrite Module 2.0 for IIS 7 (x64)

Microsoft URL Rewrite Module 2.0 for IIS 7 (x86)

Windows 10 にはインストールできない(レジストリの設定変更が必要)という話がありますが、その場合は、英語版しか見つかりませんが、以下のページからダウンロードしたものがレジストリの設定変更なしでインストールできます。

Microsoft URL Rewrite Module 2.0 for IIS (x64)

自分は英語版を使ったので、IIS Manager の Url Write の部分のみ英語になってしまいました。上の画像の表示は日本語版とは異なると思います。

Tags: , ,

Windows Server

ToolkitScriptManager と gzip 圧縮

by WebSurfer 21. November 2012 21:37

Internet Explorer (IE) の「インターネットオプション」の「詳細設定」タブで、「HTTP 1.1 を使用する」のチェックを外すと、Ajax Control Toolkit が動かないという話の紹介です。(プロキシサーバー経由になる場合は「プロキシ接続で HTTP 1.1 を使用する」のチェックを外す)

「HTTP 1.1 を使用する」のチェックマークを外す

ググって見つけた CodePlex のページ ToolkitScriptManager ignores accept-encoding http header を読んで原因がわかりました。

簡単に言うと、原因は、ToolkitScriptManager が常に gzip で圧縮したスクリプトファイルを送信するのに、IE は「HTTP 1.1 を使用する」にチェックを入れないと解凍しないことです。

詳しく書くと、以下の通りです。

  1. ToolkitScriptManager は、Microsoft Ajax Library を外部スクリプトファイルとして HTTP ハンドラ経由でブラウザにダウンロードさせるため、script 要素の src 属性に ScriptResource.axd?d=...&t=... と設定した初期ページをブラウザに返します。

    クエリ文字列のパラメータ d には、HTTP ハンドラが取得すべきファイルの指定と、送信時に圧縮するか否かの指示が含まれています。(パラメータ d, t の詳細については MSDN マガジンの ASP.NET AJAX アプリケーションの国際化 を見てください)
  2. IE の設定で「HTTP 1.1 を使用する」にチェックが入っている場合、要求ヘッダには Accept-Encoding: gzip, deflate が含まれます。チェックを外すと Accept-Encoding は含まれなくなります。

    ASP.NET 標準の ScriptManager の場合は、Accept-Encoding の有無を見て、初期ページに指定される ScriptResource.axd?d=...&t=... のパラメータ d を変えてきます。(Accept-Encoding が無ければ非圧縮、Accept-Encoding: gzip, deflate が含まれれば gzip 圧縮がパラメータ d に指定される)
  3. ところが、Ajax Control Toolkit の ToolkitScriptManager の場合は、要求ヘッダに Accept-Encoding があってもなくても、初期ページに指定する ScriptResource.axd?d=...&t=... は同じです。パラメータ d は gzip 圧縮の指定となります。

    つまり、IE の設定で「HTTP 1.1 を使用する」のチェックを外しても/外さなくても、サーバーからHTTP ハンドラ経由で受け取るスクリプトファイルは gzip で圧縮されたものになります。
  4. 一方、IE の設定で「HTTP 1.1 を使用する」のチェックを外すということは、IE では圧縮ファイルは解凍されないということを意味します。(応答ヘッダに Content-Encoding: gzip が含まれていても無視されます)。
  5. 結果、IE は Microsoft Ajax Library のスクリプトを解析できず、Ajax Control Toolkit が動かないということになります。(「文字が正しくありません。」とか「'Sys' は宣言されていません。」などのエラーが出ます)

IE8, IE9 で検証してみましたが、同じ問題が出ます。

いまどき「HTTP 1.1 を使用する」のチェックを外すことはないでしょうから実際に問題が出ることはなさそうですが、こういう問題もあるということは ASP.NET Web アプリケーションの開発者なら知っておいたほうがよさそうだと思って書いてみました。

Tags: ,

AJAX

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  September 2021  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar