スタンドアロンな Blazor WebAssembly アプリを発行、オンプレミスの IIS に配置したら HTTP 500 エラーになった件

スタンドアロン Blazor Wasm アプリを Win11 Pro の IIS に配置

とあるスタンドアロンの Blazor WebAssembly アプリを、手元の Windows 11 Pro 上の IIS に配置する機会があった。

「dotnet publish -c Release」と実行して発行を行ない、生成された「./bin/Release/net6.0/publish」フォルダ内のファイル一式を C:\inetpub\wwwroot フォルダに配置して、はい完了。

...のはずだったのだが、配置完了して https://localhost/ を Web ブラウザで開いたところ、下記内容の IIS による HTTP 500 エラーページが表示されてしまった。

HTTP Error 500.19 - Internal Server Error The requested page cannot be accessed because the related configuration data for the page is invalid.

今回発行したのはスタンドアロンな Blazor WebAssembly であり、ASP.NET Core ホストされた Blazor WebAssembly ではない。つまりサーバー側プロセスがない、言ってみれば画像ファイル群などと大差ない、ただの静的コンテンツ群を配置しようとしただけである。

にも関わらず、サーバー側エラーである HTTP 500 が発生したということはどういうことか。

最初は理由がわからず、問題切り分けになるかどうかもわからないままに、何となく、この状況から、もうひとつ別の ASP.NET Core ホストされた Blazor WebAssembly プロジェクトを発行し、発行後コンテンツを C:\inetpub\wwwroot フォルダに配置してみた。

そうしたところ、こちらはさっくり動作してしまった。

同じ IIS 上の配置なのに、両者の違いは何だろうか?

エラーメッセージの中にこそ答えがあるはず

解決できないままに改めて腰を据えて、先の IIS による HTTP 500 エラーのメッセージをよく読む。絶対に答えはエラーメッセージの中にあるはずだ。心を落ち着けてよく読むと「the related configuration data for the page is invalid.」が肝心であることがわかってきた。

つまり、「当該ページ用の関連する構成データが不正である」ということで、ここでいう「構成データ」とは web.config のことに違いない。

実際、スタンドアロンな Blazor WebAssembly アプリの発行後コンテンツを見ると、web.config ファイルが含まれているのがわかる。

そこで、この発行後コンテンツに含まれている web.config の記載内容をテキストエディタで開いて覗いてみる。

web.config の冒頭は大して珍しいものはない。下記のとおり、Blazor WebAssembly ならではのファイル種別、とくに .dll とか .wasm とかが正しくブラウザに応答返信されるよう、MIME-Type を正しく再設定しているだけである。

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

  <system.webServer>

    <staticContent>

      <remove fileExtension=".blat" />

      <remove fileExtension=".dat" />

      <remove fileExtension=".dll" />

      ...

      <mimeMap fileExtension=".blat" mimeType="application/octet-stream" />

      <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />

      <mimeMap fileExtension=".dat" mimeType="application/octet-stream" />

      ...

しかし web.config の後ろのほうに面白いものを見つけた。下記である。

   ...

  <rewrite>

    <rules>

      <rule name="Serve subdir">

        <match url=".*" />

        <action type="Rewrite" url="wwwroot\{R:0}" />

      </rule>

      <rule name="SPA fallback routing" stopProcessing="true">

        <match url=".*" />

        <conditions logicalGrouping="MatchAll">

          <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />

        </conditions>

        <action type="Rewrite" url="wwwroot\" />

      </rule>

    </rules>

  </rewrite>

  ...

上記は何かというと、いわゆる「URL の書き換え (Rewrite)」についての構成だ。

特に URL 書き換えルールの 2つ目、つまり上記 XML 中の rule ノードの 2 つ目であるが、これは SPA のフォールバックページを返す仕組みを実現している仕掛けだ。

例えば Web ブラウザからの HTTP 要求が「https://localhost/counter」だとして、しかし件の Blazor WebAssembly アプリには該当する静的ファイルは存在しない。

この場合に、上記 IIS の「URL の書き換え」によって、要求を「https://localhost/」に振り向ける、というのである。

すると、続いての「既定のドキュメント」の仕組みにより、「https://localhost/index.html」の内容がブラウザに返される、という訳である。

あとは Web ブラウザ上で、そうやって読み込まれたフォールバックページの内容を元に Blazor WebAssembly アプリコンテンツがブラウザ上に読み込まれ、Blazor WebAssembly のルーティングによってめでたく「counter」ページが表示される、という寸法だ。

GitHub Pages への配置の場合などのようにサーバー側をどうにも構成のしようがない場合は、該当コンテンツが見つからない場合 (HTTP 404) に返される HTML ファイル「404.html」にフォールバックページの内容 (つまりは index.html と同じ内容) を記載したりして凌いだりする。

が、なるほど、IIS への配置の際は、Blazor WebAssembly プロジェクトの発行後コンテンツに含まれている web.config、およびその web.config 内に記載されている「URL 書き換え」ルールによって、SPA のフォールバックページ返却の仕組みが実現されていたのである。

URL 書き換えモジュール!

ここでようやくはたと気がついた。

そういえば、IIS の「URL 書き換え」の機能って、別途追加でインストールが要るんではなかったか?

インターネットで検索してみると、果たしてそのとおり。

下記 URL から「URL 書き換え」、すなわち、「URL Rewrite」モジュールをダウンロードしてインストールするべきだったのだ。

「URL 書き換え (URL Rewrite)」モジュールをインストール完了後、再度、当該スタンドアロン Blazor WebAssembly アプリの発行後コンテンツを配置しなおし、改めて「https://localhost」を Web ブラウザで開いてみると、ようやく期待どおりのページが表示された。

もちろん、Web ブラウザのアドレスバーに「https://localhost/counter」と入力したりその後再読込を実行したりしても、ちゃんと SPA フォールバックの仕組みで、期待どおり「Counter」ページが表示された。

補足

ちなみに、ASP.NET Core ホストな Blazor WebAssembly プロジェクトであれば、「URL 書き換え」モジュールが未インストールな IIS 上でも難なく動作したのは、IIS の「URL 書き換え」モジュールがやっているのと同じような SPA フォールバックページ返却の仕組みを、ホストしている ASP.NET Core サーバーが担当しているからである。

.NET SDK 標準のプロジェクトテンプレートから新規作成した ASP.NET Core ホストな Blazor WebAssembly プロジェクトであれば、ASP.NET Creo サーバー側の Program.cs で

app.MapFallbackToFile("index.html");

の1行が最後のほうにあると思うが、それこそが、スタンドアロンな Blazor WebAssembly プロジェクトを配置した際には IIS の「URL 書き換え」モジュールにやらせていた、フォールバックページ返却の仕組みである次第。