WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

URL Rewrite Module の Outbound Rules

by WebSurfer 2017年3月20日 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

IIS ログの time-taken

by WebSurfer 2016年7月1日 14:39

IIS のログの中に time-taken という項目があります。具体的にいつからいつまでの時間かについて調べたのですが、その過程でいくつか発見があったので備忘録として書いておきます。(そもそもの話は MSDN Forum のスレッド「IIS 8.5のログの"time-taken"の値について」が発端です)

リクエスト処理の流れ

上の図は IIS7 がブラウザから要求を受けて応答を返すまでの流れを示しています。この図で time-taken はいつからいつまでになるかを簡単に書くと、上の図の ② で HTTP.sys が要求の最初のバイトを受け取ってから、⑨ で要求に対する最後の応答を返すまでとなります。

それに加えて、IIS6 からは最後のパケットに対するクライアントからの ACK を受け取るまでが time-taken に含まれるようになったとのことです。

詳しくは以下の Microsoft Support KB944884 の記事を見てください。

Description of the time-taken field in IIS 6.0 and IIS 7.0 HTTP logging

タイトルが "IIS 6.0 and IIS 7.0" となっていますが、IIS7.5 以降も同じだと思います。また、また例外の "TCP buffering is used" は ASP.NET Web アプリには関係なさそうです(公式文書などで裏は取れていませんが、この記事の下の方に書いた報告などからも ASP.NET でバッファを有効にしているとは考えに���いです)。

Microsoft の別の記事(例えば、Default Log File Settings for Web Sites とか W3C Logging)に "Time taken does not reflect time across the network" と書いてあるものもありますが、古い記述のままで修正がされてないものと思われます。

というわけで、今回分かったことを箇条書きにすると以下の通りです:

  1. time-taken は上の図で ② から ⑨ までの時間。
  2. 通常、一番最初の要求を受けてワーカープロセスを起動・初期化しログファイルを開くという操作が行われる。なので、一番最初の要求では time-taken はその分長くなる。
  3. IIS6 以降では上に紹介した KB944884 の記事に書いてあるように network time も time-taken に含まれる。それゆえ、サイズの大きなファイルを遅いネットワークでダウンロードしたりすると time-taken の値は予想よりかなり大きくなることがある。
  4. トレース情報で調べられる時間やプログラムで Stopwatch などを使って調べられる時間は上の図の ⑦ から ⑧ までの範囲内なので、当然 time-Taken の方が長くなる。

上記 3 すなわち「network time も time-taken に含まれる」を裏付けるような、time-taken の値が executionTimeout を越えているとか、プログラムのコードで実際に計った時間よりはるかに長いという報告を stackoverflow に見つけましたので、参考にリンクを張っておきます。

In our IIS logs, why do requests last 5 min and longer when executionTimeout is 110 seconds?

Difference in time-taken in IIS and ASP.NET

Tags: , ,

Windows Server

基本認証

by WebSurfer 2015年11月23日 14:19

IIS7 で基本認証を行う際のブラウザとサーバーのやり取りを調べましたので備忘録として書いておきます。

基本認証のやり取り

上の画像は IIS7 と IE9 で基本認証を行った場合の要求 / 応答を Fiddler2 でキャプチャしたものです。

  1. 最初の要求に対してはサーバーから応答ヘッダに WWW-Authenticate: Basic realm="xxx" を含む HTTP 401 応答が返ってきます。上の画像の #2 がそれです。xxx には IIS7 の場合ホスト名が入ります。
  2. ブラウザはそれを受けてユーザーに[ユーザー名]と[パスワード]の入力を促すダイアログを表示します。
  3. ユーザーがダイアログに[ユーザー名]と[パスワード]を入力して[OK]ボタンをクリックすると、ブラウザは 1 で要求したページを再度 GET 要求します。上の画像の #3 がそれです。
  4. その際、ブラウザは認証用のヘッダ Authorization: Basic UGFwaWt...(上の画像で赤枠で囲った部分を見てください)をサーバーに送ります。UGFwaWt... の部分は[ユーザ名]と[パスワード]をコロン ":" でつなぎ Base64 でエンコードしたものです。
  5. サーバーはこのヘッダを見てユーザーを認証し、HTTP 200 ステータスコード(成功)と共に要求されたコンテンツをブラウザに送信します。
  6. これ以降、ユーザーがブラウザを閉じない限りホスト名 xxx に対しては認証用のヘッダ(画像で赤枠で囲ったものと同じ)が要求ヘッダに含まれて送信され、要求のたび自動的に認証が行われるようになります。上の画像の #4, #5 がそれです。

以上、基本認証でのブラウザとサーバーのやり取りを簡単にまとめてみました。

フォーム認証と Windows 認証の場合は、それぞれ先の記事「Forms 認証のログイン・ログオフ動作」と「非ドメインユーザーの誘導」に書きましたので興味がありましたら見てください。

Tags: ,

Authentication

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年4月  >>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar