Server.Transfer は要求元のクライアントに往復しないことを理解しています。
私が知ることができなかったのは、制御が転送先の新しいリクエストハンドラーに直接渡されるか、またはリクエストライフサイクル全体が再度実行されるかどうかです。
ライフサイクル全体が転送 URL を使用して再度実行されると想定していますが、これが事実であることを確認したかったのです。
実験でわかったのがこちら。
Server.Transfer
リクエストのライフサイクル全体を使用すると、再実行されません。
独自のモジュールを作成し、それをリクエスト ライフ サイクルにフックし、Server.Transfer
そのモジュールから呼び出すと、残りのリクエスト ライフ サイクルはスキップされ、ページ ライフ サイクルがすぐに開始されます。
転送ページのライフ サイクルが完了すると、要求のライフ サイクルはティアダウン イベントで再開されます。破棄イベントの HtppContext は、転送元の元のものになることに注意してください。つまり、URL と QueryString の値は元の要求と同じになり、転送先のページの URL と QueryString の値にはなりません。
Server.Transfer
HttpContext.Request
は、転送先のページのページ ライフ サイクル中に新しい URL と QueryString 情報を含むようにオブジェクトを変更します。
ページではないがテキストベースのリソース (something.xml など) に転送すると、そのページのコンテンツは、エンコーディングが text/html に設定された状態のまま正確に返されます。
ページではなく、テキストベースではないリソース (something.pdf など) に転送すると、HttpException エラーがスローされます。これは、このリソースのカスタム ハンドラを定義した場合でも発生します。
そのままの状態で渡されただけです。ページのライフサイクルは転送先のページに対して実行されますが、リクエストのライフサイクルは再度実行されません。
http://msdn.microsoft.com/en-us/library/ms525800(v=vs.90).aspx
Server.Transfer は、Response.Redirect メソッドの効率的な代替手段として機能します。Response.Redirect は、ブラウザーに別のページを要求するように指定します。リダイレクトは新しいページ要求を強制するため、ブラウザーは Web サーバーに対して 2 つの要求を行い、Web サーバーは余分な要求を処理します。IIS 5.0 では、サーバー上の別の ASP ページに実行を転送する新しい関数 Server.Transfer が導入されました。これにより、余分なリクエストが回避され、システム全体のパフォーマンスが向上し、ユーザー エクスペリエンスも向上します。
このリンクも役立ちます -
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm