問題タブ [request-pipeline]

サーバー上のサイトに割り当てられる前に、IISレベルで受信要求を操作することは可能ですか？

基本的に、これを書き直したい-

これに-

また、IISが要求が属するサイトを選択する前にこれを行う必要があるため、この時点より前にホストヘッダーを変更する必要があります。

可能ですか、それともクレイジーですか？IIS7を実行しています。

python（またはphp）のようなスクリプト言語では、.netやjavaのようにバイトコードにコンパイルされません。

つまり、これは、すべてのリクエストで、アプリケーション全体を調べて解析/コンパイルする必要があることを意味しますか？または、少なくとも特定のコールスタックに必要なすべてのコードはありますか？

IIS を夢中にさせている MVC3 アプリがあります。私も。

SQLException が発生した場合 (つまり、ストアド プロシージャが見つからない場合) リクエスト パイプラインが壊れ、ユーザーに「申し訳ありませんが、リクエストの処理中にエラーが発生しました」と表示され、イベント ビューアには何も記録されません。リクエストの追跡はまったく有用な情報を提供しませんが、ここで見ることができます。興味深い部分は 6448 行目で、エラー コードは「操作は正常に完了しました」です。

楽しい部分は次のとおりです。

• 私のマシンのwin7 64ビット - 期待どおりに動作し、YSODが表示されます
• 私のホスティング マシンの 1 つ win2008 Web サーバー 32 ビット - 期待どおりに動作し、YSOD が表示されます
• クライアントのホスティング マシン win2008 R2 サーバー コア 64 ビット - 上記のようにパイプラインが壊れる
• (テスト目的で) クライアントのホスティング マシン win2008 Web サーバー 64 ビット - 上記のようにパイプラインが壊れる

更新: この問題は SQLException に限定されません。ANY Exception 、つまり throw new Exception("Bla") は、上記のようにパイプラインを壊します。

バックオフィスアプリケーションとして使用されるASP.NETMVCアプリケーションに認証Cookieを送信するASP.NETアプリケーションがあります。

認証Cookieのすべてのコントローラーアクションをチェックするグローバルフィルターを追加しました。Cookieが存在する場合、ユーザーはページに入ることができます。

コードは次のようになります。

Application_BeginRequest反対側からは、Global.asaxファイルのイベントでASP.NETアプリケーションから送信されたCookieを確認できます。

クッキーが消えた場所と理由は？MVCリクエスト処理パイプラインのどの部分でCookieが破棄されましたか？

. _ HttpApplication_ _ _HttpApplicationHttpApplicationHttpContext.Current.ApplicationInstance

ただし、パイプラインに追加された にコードがあり、発生IHttpModuleするイベントのパラメーターの 1 つは であり、Object senderにキャストされますHttpApplication。HttpContext.Current.ApplicationInstanceこれを適切にモックするために、イベントの送信者パラメーターではなく参照するプロキシ クラスを使用したいと思います。リクエスト パイプラインのドキュメントを読んだ限りでは、この 2 つがどのように異なるのかはわかりませんが、それを本番環境に投入して、それが本当かどうかを確認するには十分ではありません。:)

彼らはいつも同じですか？そうでない場合、明示的に参照が渡さHttpApplicationれた場所で参照をモックする方法について、誰かが良い提案をしていますか?IHttpModuleHttpApplication

AcquireRequestState でかなりの時間を要するかなりの数の ajax 呼び出しを検出しました。旅行中に ASP.Net のセッション ロック gem に出くわしたため、カスタム セッション状態ハンドラーを実装しました (以下のリンクに基づく)。

変更を加えてデプロイした後、AcquireRequestState で非常に急激な低下が見られましたが、PreExecuteRequestHandler に置き換えられていました。

今朝、突然、OWIN を含めたことに気づきました。これが、おそらく PreExecuteRequestHandler が非常に多くの時間を費やしている理由でした。次に、それを削除し、コードをデプロイした瞬間、PreExecuteRequestHandler がリストから消えました。悲しいことに、これはほぼ同じコストで再び AcquireRequestState に置き換えられました。

部分ビューを返す AJAX 呼び出し、プリミティブ型または JSON オブジェクトを返す AJAX 呼び出しは、スループットが高いにもかかわらず、ほとんど影響を受けていないようです。

したがって、これにより、私が完全に困惑している3つの質問が残り、1つの答えが他の2つの答えにつながると思います.

1) OWIN のインストール時にコストが AcquireRequestState から PreExecuteEventHandler に移動したのはなぜですか? OWIN で IRequireSessionState としてマークされているものはありますか? (AcquireRequestState はマネージ パイプラインの早い段階で発生する必要があったことを理解しています)

2) AcquireRequestState 内で実際に何が起こっているかについて、より多くの情報を取得するにはどうすればよいでしょうか? それとも、JSON オブジェクトを返し、それを使用して UI に必要なものをレンダリングすることに時間を費やしたほうがよいのでしょうか?

3) New Relic で /{controller}/{action}/{id} にマップされ、上記のリクエストの実行中に完全にスタックするリクエストがいくつか (ごく少数ですが) 見られます。これは、プロジェクト内にあるコントローラーとアクションにのみルーティングするようにルーティングに制約を設定しているにもかかわらずです。

PS: これは次のように見えますが、New Relic でも見られます: AcquireRequestState の長い遅延

からのカスタム セッション モジュール: すべての ASP.Net Web サイトが遅い理由を発見しました。