WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

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

IIS ログの time-taken

by WebSurfer 1. July 2016 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

二重スラッシュを含む URL 書換

by WebSurfer 23. January 2015 14:10

IIS の URL Rewrite モジュールを使用して aaaa/1/2/3 という URL を test.aspx?x=1&y=2&z=3 というように書き換えることを考えます。

URL の書き換え

この時、たとえば上の画像のように 2 つ目の値をスキップした aaaa/1//3 という URL を test.aspx?x=1&y=&z=3(y に値がないところに注目)に書き換えたい場合はどうすればいいでしょうか?

IIS7 の URL Rewrite モジュールを使って、普通に(というか、あまり深く考えずに)書換ルールを作ると以下のようにすると思います。

<rewrite>
  <rules>
    <rule name="DoubleSlash">
      <match url="aaaa/(.*)/(.*)/(.*)" />
      <action 
        type="Rewrite" 
        url="test.aspx?x={R:1}&y={R:2}&z={R:3}" />
    </rule>
  </rules>
</rewrite> 

IIS マネージャーの「テストパターン」ダイアログ上で、[テスト対象データの入力(D):]テキストボックスに aaaa/1/2/3 とか aaaa/1//3 などのテストパターンを入力してテストすると、 {R:1}, {R:2}, {R:3} には期待通りの結果が得られます。

なので、ブラウザから aaaa/1/2/3 とか aaaa/1//3 などで呼んでも同様に aaaa/(.*)/(.*)/(.*) にマッチして、test.aspx?x=1&y=2&z=3 とか test.aspx?x=1&y=&z=3 に書き換えられると期待すると思います。

しかし、ブラウザから aaaa/1//3 で呼ぶとダメです。ダメな理由は、IIS が aaaa/1//3 を aaaa/1/3 に書き換えてしまうからです。詳しく書くと以下の通りです。

  1. ブラウザからは aaaa/1//3 で要求が出る。
  2. それを受けた IIS は aaaa/1//3 を aaaa/1/3 に書き換えてしまう。
  3. aaaa/1/3 が URL Rewrite モジュールに渡される。
  4. aaaa/1/3 は aaaa/(.*)/(.*)/(.*) にはマッチしない。マッチしないので書き換えは行われない。
  5. 書き換えが行われないので、IIS は aaaa/1/3 で指定されるリソースを探す。
  6. そのようなリソースは存在しないので HTTP エラー 404.0 - Not Found となる。

ちなみに、aaaa/1/2/3 であれば期待通り test.aspx?x=1&y=2&z=3 に書き換えられ、test.aspx ページ内でクエリ文字列は正しく取得できます。

上記 2 がどうして分かったかと言うと、6 で表示されるエラー画面で「要求された URL http://aspnet4site:80/aaaa/1/3」となっていたからです。(aspnet4site は自分の開発マシンで使っているホスト名です)

というわけで、上記 2 を何とかしないと URL Rewrite モジュールでは対処できないということになります。

それを何とかする手段が IIS Server Variables の UNENCODED_URL を使用して IIS が処理する前の URL を取得して、それに書換ルールを適用することです。

詳しい手順は Microsoft IIS.net の記事 URL Rewrite Module Configuration Reference の中の「Using server variables in rewrite rules」および「Using back-references in rewrite rules」というセクションが参考になると思います。

具体的な書換ルールのコードは、今回のケースでは以下のようになります。

<rewrite>
  <rules>
    <rule name="DoubleSlash">
      <match url="^aaaa/" />
      <action 
        type="Rewrite"
        url="test.aspx?x={C:1}&y={C:2}&z={C:3}" />
      <conditions>
        <add 
          input="{UNENCODED_URL}" 
          pattern="^/aaaa/(.*)/(.*)/(.*)" />
      </conditions>
    </rule>
  </rules>
</rewrite>

上記のルールで、aaaa/1/2/3 でも、aaaa/1//3 でも、aaaa//2/3 でも、 aaaa/// でも、その他全てのパターンで期待通り書き換えられるのを確認できました。

Tags: ,

Windows Server

About this blog

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

Calendar

<<  September 2019  >>
MoTuWeThFrSaSu
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

View posts in large calendar