[転載]IIS 7以上のASPに対して.NETサイトカスタムエラーページと異常ログのまとめ

9811 ワード

IIS 7以上のASPに対して.NETサイトカスタムエラーページと異常ログのまとめ


 
汪宇傑
2014-1-11土曜日02:31

455 Reads 1 Comments


カスタムエラーページと異常記録は古い話題ですが、今でも爆発します.私が何度も実験をして経験と原則を総括した後、本文を書いて、すでに後世を警戒しています.
本明細書の範囲と制限
  • 本明細書は、IIS 7またはそれ以上のバージョンに配備するASPにのみ適用される.NET 4.0統合モードアプリケーション.IIS 7以上は、Windows Server 2008以上のサーバが適用されることを意味します.WS 2012 R 2,IIS 8で測定しました.
  • 本明細書の方法はいずれもASPに適用する.NET WebFormとMVCアプリケーション.

    • 本文の対象とする問題
  • 静的エラーページと動的エラーページのどちらがいいですか?ASPをどのように設計すればいいですか.NETサイトエラー処理?
  • エラーページの後ろにaspxerrorpath=...という小さな尻尾が付いてほしくありません.
  • 私のカスタムエラーページはVSでデバッグしたほうがいいのに、どうしてサーバーに配置して出られないのですか.
  • 私のカスタムエラーページは正常に表示できますが、なぜ返されたHttpステータスコードが正しくありませんか?
  • 異常ログはどのように記録すればいいですか?比較的良い実践はありますか?

    • 一、エラーページの選択
    静的htmlページをエラーページとして選択するか、使用するかを選択する.aspxまたはMVC Viewでエラーページを表示してもいいですか?この問題は多くの人の好みが違う.html静的ページをエラーページとして使用することを強くお勧めします.分析を参照:
    まず、ダイナミックページを使う人は、エラーの要約を表示したり、ログを記録したり、正しいステータスコードを返したりする3つの問題を解決するためにほかならない.しかし、ダイナミックページの最大の問題は、それ自体がASPを通過することである.NETとバックグラウンドコードは処理して、もしあなたのバックグラウンドコードが爆発したならば、あるいはASP.NET自身が爆発したら、あなたのエラーページが要求されると、それ自体が別のエラーを引き起こします.静的htmlにはこの問題はありません.MVCにErrorControllerを専門に作るのはなおさらだ.MVCはASPに基づく.NETの上の、MVCのControllerはMVC自身の誤りをつかむことしかできなくて、ASPをつかめません.NETの間違いは、あなたの間違いがMVCレベルではないとき、ErrorControllerには何の役にも立たないという意味です.例えば、あなたが配置したMVCアプリケーションにMVCのdllが欠けている場合、MVCフレームワーク自体が走ることができません.このエラーはどのように捕まえますか?
    また、インターネットサイトでは、訪問者にエラーの要約を表示するべきではないと思います.これは非常に安全ではありません.だからダイナミックページを使う必要は全くありません.
    正しいステータスコードを返す問題は、多くのパートナーが自分のエラーページが表示できることに気づいたが、戻ったステータスコードは200 OKなので、仕方なくダイナミックページでResponseと書く.StatusCode=500というコードで強引にやっつける.これは後述する文章に解決策があるので、ステータスコードのためにダイナミックページを冒険しないでください.ある仲間は私にResponseを1筆しか書かないと聞く.StatusCode=500はどんなリスクがありますか?ほほほ、このような状況を考えてみます:404.cshtml、razorエンジンのdllがなくなりました・・・
    また、1つの原則は、エラーページが独立していることです.もしあなたの静的なページが画像やCSSなどの外部資源を使うならば、ページの中に埋め込んで、単一のファイルを作ることを提案して、誤ったページを表示する時関連資源を要求して再び異常を起こさないようにします.友达はまた闻いて、CSSとピクチャーなどを頼んで、肿れて异常を引き起こすことができますか?これを見てごらんaxd?image=...、ほほほ.
    では、静的ページを使った後、ログを記録するにはどうすればいいのでしょうか.正しい方法はGlobalに渡すべきだ.asaxの「Application_Error」イベント処理.後で翔解があります.
    二、構成エラーページ:customErrors VS httprerrors
    まず、エラーページの表示方法は2つあります.IISを開くと、2つの間違ったページが表示されます.のNET Error PagesとError Pages.
    開発者の立場から言えば、ASP.NET Sectionの下の「.NET Error Pages」がwebです.confg/system.Web/customErrorsノード.IIS Sectionの下の「Error Pages」はwebです.config/system.WebServer/http Errorsノード、これはIIS 7以上特有です.
    IIS上でこの2つの変更は実際にはwebを修正している.configファイル.
    では、カスタムエラーページを構成するには、どちらを使用しますか?私の1つの原則は、IISにASPに依存せずにユーザーにエラーページを表示させることです.NET. 猿因は以下の通りである.
    CustomErrorの質問:
    a)デフォルトでは、CustomErrorは302リダイレクトでエラーページを表示します.クライアントが404ページを要求すると、302が200 OKに続くことになります.人間にとってはOKです.結局、ユーザーは友好的なエラーページを見ましたが、検索エンジンはこの存在しないアドレスが正常なページだと思って、404ページを検索結果に収めます.エラーが発生するたびに、URLの後ろにaspxerrorpathという小さな尻尾が付いてきます.例えば、
    http://yoursite.com/404.html?aspxerrorpath=/somethingnotexsit
    b)redirectMode=「ResponseRewrite」を構成すると、09年にバグがMS Connectに提出されたという問題が発生しますが、マイクロソフトはfixというバグを計画していません.すなわち、このモードはVSに付随ASP.NET Development Serverでは有効で、ブラウザには解析後のHTMLページが表示され、IISに配備された後、ブラウザにはraw html、つまりあなたのエラーページのHTMLコードが表示されます.そして、この行為は確定性がなく、あなたのウェブサイトが環境を変えてどのように爆発するか知っています.
    c)IIS 7以上のバージョンの特殊性:統合モードではIISのエラーページがASPより優先される.NETエラーページ、すなわちIISのデフォルトエラーページは、あなたが構成したCustomErrorsページを上書きします.これは、VSでデバッグするのが良いため、サーバに配備すると爆発します.
    IIS 7以降、あなたの構成によって、ユーザーの要求が必ずしもASPにあるわけではありません.NETパイプライン上処理.異常を起こす箇所がASPでない場合NETでは、CustomErrorsのエラーページは表示されません.
    したがって、CustomErrorsの代わりにhttprerrorsノードを使用してエラーページを構成することを強くお勧めします.
    三、FileかExecuteURLか:httprerrorsの正しい配合
    まず、正しい構成サンプルを貼ります.Fileで配置されています.
    2つの点に注意してください.
  • スラッシュは、Windowsファイルパスのスラッシュ""であり、URLのスラッシュ"/"
    • ではない
  • Path「~」または「」で始まる
    • は使用しないでください.
    なぜか聞かないでください.私も知りません.どうせそうすればいいです.
    残念ながらExecute URLを使用すると、URLパスは「/」で始まるしかありません.
    そして、あなたのエラーページは、正しい404、500などのエラーコードではなく200 OKを返します.これは私の以前の文章に書いたことがあります.
    http://diaosbook.com/Post/2012/6/24/correct-way-to-implement-custom-error-page-return-statecode-instead-of-http-200
    Fileとは、エラーが爆発するとIISがターゲットFile、例えば404をhtmlの内容は、現在のResponseストリームに詰まっており、Httpステータスコードを保持するのは404である.これが私たちが望んでいることです.
    四、異常ログ記録
    文章は最初から問題を提起して、木はダイナミックなページがあって、どのようにエラーのログを記録しますか?私のやり方はGlobalです.asaxで処理します.
    Application_Errorイベントサンプルコードは次のとおりです.
    var exception = HttpContext.Current.Server.GetLastError(); if (null != exception) { // by default 500 var statusCode = (int)HttpStatusCode.InternalServerError; if (exception is HttpException) { statusCode = new HttpException(null, exception).GetHttpCode(); } else if (exception is UnauthorizedAccessException) { // to prevent login prompt in IIS // which will appear when returning 401. statusCode = (int)HttpStatusCode.Forbidden; } if ((LogHttpNotFound && statusCode == 404) || statusCode != 404) { if (null != _loggerFunc) { LoggerFunc(string.Format("ASP.NET Error Captured, Request URL: {0}, Exception:", HttpContext.Current.Request.Url), exception); } } ExceptionInfo = exception.Message; _statusCode = statusCode; }

    小さなアドバイスは404のエラーを記録しないことです.あなたのサイトはインターネット上で様々な検索エンジン、スキャンツール、ハッカーに爆発されるため、辞書でディレクトリを推測する攻撃手段があります.404に戻ると存在しません.403に戻ると存在します.だから、このような退屈なハッカーに出会ったとき、404リクエストを記録したら、あなたのログはとても大きくなります......
    ログ用のコンポーネントはNlogで、構成が簡単で、使いやすいです.Log 4 netという商品はもう久しぶりに更新されました.
    ログモジュールを自分で設計することにした場合は、2つの原則を覚えておいてください.
    ログモジュール自体は、自分が爆発したためにシステム全体の動作に影響を与えることはできません.すなわち、ログモジュール内の異常は外に泡を立てるべきではありません.
    ログの同時書き込みを考慮すると、ログ操作はFire and Forgetであり、アプリケーションがログの書き込みを待つことはできません.
    五、まとめ
  • は、エラーページとして静的htmlページを採用している.
  • はhttprerrors構成エラーページを採用し、IIS 7以上の環境と互換性があり、正しいエラーコードを返し、aspxerrorpathの小さなしっぽを取り除くことを目的としている.
  • ログはGlobalに書かれています.asaxで、Application_Errorイベントに記録されます.

    • 転載先:https://www.cnblogs.com/sherlock99/p/4109035.html
    asp.NetMVC Razor構文(1)
    SpringMVC js/css/imageパスの問題