これは、カスタム エラーが実際にどのように呼び出されるかについての私の誤解と、(IMHO) asp.net mvc でのエラーの処理が少し混乱しているという事実が原因の 1 つです。
最初の問題は、多くのアクション メソッドで、ブログ投稿などのオブジェクトの存在を確認し、ブログ投稿が null の場合は HttpNotFoundResult を返すことでした。これにより、404 エラー用に設定したカスタム エラー ページが表示されると想定していました。
しかし、そうではありません。HttpNotFoundResult を返すと、単に応答のステータス コードが 404 に設定されます。残りは IIS によって処理され、IIS 404 エラー ページが表示されます。独自のカスタム エラー ページがある場合はブラウザによって処理されます。
ここでの 1 つの解決策は、リクエストが asp.net によって処理されるため、カスタム エラー ページを使用する HttpException を返すことです。
代わりに、http ステータス コードと共にビューを指定できる新しい ActionResult を作成することにしました。私は例外をスローするよりもこれを好みました。
次の問題は、デフォルトで新しい MVC プロジェクトに貪欲なルートが定義されていることです。/foo/bar
デフォルトの MvcHandler にリクエストを行うと、 というコントローラーが検索されFoo
ます。見つからない場合は 404 を返します。
デフォルト ルートを削除し、貪欲なルートはありませんでした。これは、どのルートにも一致しない URL が asp.net によって処理されず、IIS にフォールバックすることを意味していました。
ここでの解決策は、ルーティング構成の下部にワイルドカード ルートを作成して、他のすべての要求と一致させ、ステータス コードを 404 に設定し、カスタム ビューを表示するカスタム PageNotFound アクションに転送することでした。
指摘する価値のあるいくつかのこと。
httpErrors errorMode="Detailed"
カスタム エラー ページが IIS/IISExpress に表示されるように設定する必要があります。ただし、残りはそのままにしておくことができます。
defaultRedirect
セクションにパスを設定しcustomErrors
ても、500 エラーには影響しません。これは、グローバルHandleErrorAttribute
が 500 個のエラーすべてを処理し、表示する「エラー」というビューを探すだけだからです。これは、カスタム エラー ページが実際にコントローラー アクションである場合、呼び出されないことを意味します。上記は、明示的に 500 エラー ページを指定した場合でも当てはまります。
- ただし、明示的に指定されていない場合は他のステータス コードに使用されるため、defaultRedirect パスはそのままにしておく必要があります。