私はすべての着信要求と発信応答をASP.NET WebAPIプロジェクトに記録しようとしています。私がDelegatingHandlerと同意している間、私の雇用者はHttpModuleを使用することを主張します。あなたは彼女に説明してください。DelegatingHandlerで、HttpModuleではないのはなぜですか？または私は間違っていますか？HttpModuleとDelegatingHandler - 利点/欠点？
私はDelegatingHandlerを使用します。 DelegatingHandlerはWeb APIパイプラインの一部であり、任意のホストで実行できます。 HttpModuleはWeb APIの一部ではなく、IISが必要です。
直接あなたの質問に関連していないが、私は違いを含め2を強調し、次のMSDN記事から引用するつもりです：
HTTPモジュールこれは、IIS上で実行されているWeb APIのオプションです。 。 HTTP モジュールは、セキュリティコードがIIS パイプラインの一部として早期に実行されるようにします。 HTTPモジュールから確立されたプリンシパルは、後で パイプラインで実行されるIISコンポーネントを含む、すべてのコンポーネントに対して利用可能な です。たとえば、AuthenticateRequestイベントに応答してHTTP モジュールによってプリンシパルが確立されると、プリンシパルは ログのcs-usernameフィールドに正しくログされます。ユーザー名は です。 HTTPモジュールの最大の欠点は、 粒度の欠如です。 アプリケーションに入るすべての要求に対してHTTPモジュールが実行されます。 などの異なる機能を持つWebアプリケーションの場合、HTTPモジュール の認証を一方向に強制するHTMLマークアップの生成、Web APIなどは一般的には柔軟性がありません。つまり、 のアプローチです。 HTTPモジュールを使用する際のもう1つの欠点は、この場合はホスト-IISCに の依存関係があることです。 ASP.NETのWeb APIで提供さ
メッセージハンドラ拡張オプションは、 は、セキュリティのためのメッセージハンドラを使用する際の最大の利点は、それは、それゆえ、しないのASP.NET Web APIフレームワークの 概念だと基盤となるホストまたはサーバーに依存します（ ）。また、メッセージハンドラは、 Web API要求に対してのみ実行されます。メッセージハンドラを使用することの欠点は、細かい制御の欠如である です。メッセージハンドラは、すべての要求または特定のルートに対して グローバルハンドラとして実行するように設定できます。与えられた ルートの場合、複数のコントローラを持つことができます。これらのすべてのコントローラとそれらに含まれるアクションメソッドの は、そのルート用に設定されたメッセージハンドラによって強制される同じ認証 を共有する必要があります。他の ワードでは、メッセージハンドラ によって実装された認証の最小単位はルートレベルです。