ワーカープロセスとはアプリケーションプールが実行された際のプロセス。
複数のアプリケーションプールを共存させることも可能。
表示される各項目の説明は以下の通り
また、この情報はコマンドでも表示できる。
とあったが、以下のようなエラーとなった。
WASサービス自体は起動しているのだが・・・・。
PowerShellで実行すると大丈夫だったので深くは追及しない。
IISでは自らのサービスの状態と挙動を監視するための機能を提供している。
ここではアクセスログを説明する。
IISのアクセスログは規定で以下に記録される。
C:\inetpub\logs\Logiles
さらにWebサイト、FTPサイトごとにフォルダーが分割され、それぞれサイトIDが付加されたフォルダに保存される。
（例）
サイトIDはIISマネージャでサイトの詳細設定を表示すると確認できる。
アクセスログはテキスト形式で保存されているため、メモ帳などでその中身を確認できる。
規定で出力される内容は以下の通り。
Excelなどで分析するか、無償で提供されている「Log Parser」というツールで分析しても良い。
Log Parser 2.2 日本語版
ログファイルは自動では削除されないので適当な時期に整理したほうが良い。
IISで指定可能なアクセスログの形式は以下の通り。
＜ログの形式の変更方法＞
ログファイル形式が「W3C」の場合に限り、ログファイルが記録する項目を変更することができる。
規定では1日1ファイルに記録されるが、変更することも可能。
ログについての詳細な設定方法は以下のドキュメントを参照。
IIS 7 でログ記録を構成する
IISで実行できるアプリケーションは、「ASP」「ASP.NET」「PHP」他、何種類かあるようだが、メインはやはり「ASP.NET」になると思われるので、ここでは「ASP.NET」のみ簡単に纏めておく。
| <%@ Page Language="C#" %> <html> <head id="Head1" runat="server"> <title></title> </head> <body> <form id="form1" runat="server"> <h3> <%="Hello World" %> </h3> </form> </body> </html> |
以前も少し調べたことがあるのだが、どうも理解できていないのでもう一度挑戦。
MTG Blog: ◆IISエラーページのカスタマイズ
実際にエラー応答をどう設定するかとなるとIIS8になっても設定画面は変わりが無く、良くわからない。
前回に引き続きもう一度手探りで調べてみる。
まずは「静的ファイルのコンテンツをエラー応答に挿入」という事なのだが、これは単純に静的カスタマイズページを返すという事なのか、もともとのテンプレート的なエラーページに、部分的にエラーページを挿入できるということなのか？
英語も見てみたが、特にMSお得意の誤訳といった感じでもなかった。
Web.configで設定するサーバー屋さんからすれば当たり前の事なのか、さっぱりここら辺の情報は見つからない。
我々プログラマーからすると、どうしてこんなに単純なことが簡単にできないのか不思議だ。
とりあえず、カスタマイズしたファイルを指定してみる。
以前調べたときに、「このサイトでURLを実行」に指定してうまくいったのと同じ記法で指定してみた。
これで存在しないファイルにアクセスしてみると、
といった表示になり、「MyError.html」は表示されない。
パスの書き方を色々変えてみても一向にうまくいかない。
前回と同じだ。
ググってみてもやっぱり前回同様、これといった情報を見つけられない。
仕方がないので地道にログを探っていくこととした。
まずは「C:\inetpub\logs\LogFiles\W3SVC1」にある「IISアクセスログ」を見てみたが、特に有益な情報は無し。
そこで、「トレース」機能をインストールして「失敗した要求トレース」なるものを見てみる。
IIS: ◆「失敗した要求のトレース」を使う
すると、404のエラーが発生した後に、カスタマイズしたエラーファイルにアクセスしている部分が見つかった。
これを見ると、明らかに「/MyError.html」の書き方が間違っているのがわかる。
そこで「MyError.html」に修正して再度見てみる。
すると、どうみてもカスタマイズした「MyError.html」の内容をリターンしているのが判る。
ん～、どうやら問題はサーバー側ではなくクライアント側のようだ。
こんどは、実在しないページを要求したときのクライアント側のトレースを見てみる。
IEでは「F12」を押すと簡単にトレースが見れる。
「ネットワーク」タブを選択し、「キャプチャの開始」をクリックしてから実在しないページにアクセスしてみる。
「キャプチャの停止」をクリックし「詳細ビューに移動」をクリック
「応答本文」タブをクリックして表示させると、
あれー、ちゃんと来てるじゃない。
試しに「Chrome」で見てみると、あらら、カスタマイズページが表示されるじゃないですかぁ。
IEの問題？
調べてみると、以下に説明があった。
IIS 7.0 で HTTP の詳細エラーを使用する方法
これによると、「400～500」の範囲の状態コードがサーバーから帰ってきた場合はIE側でエラー表示を差し換えている模様。
この差し替えをやめるには、「インターネットオプション」「詳細設定」「ブラウズ」にある「HTTPエラーメッセージを簡易表示する」のチェックをはずす。
これで、前回の調査から苦節１年やっと「静的ファイルのコンテンツをエラー応答に挿入」することができた。
静的ファイルがうまく返せたので、今度は「クライアント言語でえらーファイルを返す」に挑戦。（個人的には使うことはないと思うが）
これで静的ファイルはOKと思ったのだが、たまたまエラーファイルをサブディレクトリにと思ったら、これがなぜかうまくいかない。
以下のような指定をして、
「カスタムエラーページの編集」に戻って「OK」ボタンを押すと
といったエラーが表示されて保存することができない。
いや～、ルートディレクトリなんて指定したつもりはないんだけど・・・。
どうにもこうにもエラーを回避できない。
調べてみると、以下のMSの資料を見つけた。
[ローカライズされたカスタム エラーのパスの設定] ダイアログ ボックス
どうもこれを見ると、エラーメッセージが言う通り絶対パスを指定するっぽい。
（カレント指定はできたのに・・・、不思議な仕様だ）
まぁ、仕方がないので絶対パスで指定してみる。
おぉー、今度は保存できた！！
しか～し、ブラウザでアクセスしてみると、
こっちでは「相対パス」を指定しろと怒られる。
一体全体誰を信じれば良いの？
このエラーコードでググってみるとMSの人のブログが見つかった。
MSDN Blogs
これを見ると、絶対パスを許可するように設定を変更しろとの事。
手順は以下の通り
これでやっとカスタマイズしたエラーが表示された。
本当に、こんな複雑怪奇なものが正しい仕様なのだろうか・・・。
なんとか「静的ファイル」の指定がうまくいったので、今度は「このサイトでURLを実行」
こちらは以下のような指定で単純にうまくいく。
記入例にあるように「aspx」ファイルでも大丈夫だ。
結局、「静的ファイルのコンテンツをエラー応答に挿入」と「このサイトでURLを実行」では何が違うのか。
字面だけでは感じ取れないが、「静的」の方は状態コード「404」を返し（今回の場合）、「URLを実行」では「200」を返しているのが根本的な違いではなかろうか・・・。
なので、「URLを実行」の方はブラウザの設定によらず最初からカスタマイズしたエラーページを表示することができた。
では、実際どう使い分けるのか？
はっきり言って「意味不明」
「IE」のデフォルト設定を考えれば「静的」の方はデバッグ情報などを表示するのかとも思うが、なぜにこちらにしか言語対応がないのか・・・。
以下のような指定でうまくいく。
こちらはリダイレクトなのでアドレスも指定したものに変わっている。
※使い分けは別にして、３通りの指定の違いは結局クライアントに返す状態コードの違いという事のようだ。
