Server.Transfer対 Response.Redirect

違いは何であるServer.TransferとはResponse.Redirect？

• それぞれの長所と短所は何ですか？
• どちらが適切であるか。
• いつ適切ではないのですか？

Response.Redirectメッセージ（HTTP 302）をブラウザに送信するだけです。

Server.Transfer ブラウザは何も知らずに発生し、ブラウザはページを要求しますが、サーバーは別のコンテンツを返します。

Response.Redirect()新しいページに移動し、アドレスバーを更新して、ブラウザの履歴に追加します。ブラウザで戻るをクリックできます。

Server.Transfer()アドレスバーは変更されません。あなたは反撃することはできません。

私が使用Server.Transfer()私はつもりだどこユーザーが表示したくないとき。「読み込み中」タイプのページに表示されることがあります。

それ以外の場合は、常にを使用しますResponse.Redirect()。

Response.Redirect簡単に言うと、単にブラウザに別のページにアクセスするように伝えます。Server.Transferサーバーリクエストを減らし、URLを同じに保ち、少しバグバッシングすることで、クエリ文字列とフォーム変数を転送できます。

私が見つけて同意したもの（ソース）：

Server.Transferは、などのステートメントを使用してユーザーを別のページに移動するという点で似ていますServer.Transfer("WebForm2.aspx")。ただし、このステートメントにはいくつかの明確な利点と欠点があります。

まず、Server.Transfer サーバーリソースを節約して別のページに転送します。ブラウザーにリダイレクトするように指示する代わりに、Webサーバー上の「フォーカス」を変更して要求を転送するだけです。つまり、通過するHTTPリクエストの数がそれほど多くないため、Webサーバーへの負荷が軽減され、アプリケーションの実行が高速になります。

ただし、「転送」プロセスはサーバーで実行されているサイトでのみ機能するため、注意が必要です。Server.Transferユーザーを外部サイトに送るために使用することはできません。それしかResponse.Redirectできない。

次に、Server.Transferブラウザで元のURLを維持します。これは、デバッグ時の混乱を招く可能性はありますが、データ入力手法の合理化に役立ちます。

それだけではありません。このServer.Transferメソッドには、「preserveForm」という2番目のパラメーターもあります。これをに設定するとTrue、などのステートメントをServer.Transfer("WebForm2.aspx", True)使用して、転送先のページで既存のクエリ文字列とフォーム変数を引き続き使用できます。

たとえば、WebForm1.aspxにTextBox1というTextBoxコントロールがあり、preserveFormパラメーターをTrueに設定してWebForm2.aspxに転送した場合、を参照することで元のページのTextBoxコントロールの値を取得できます Request.Form("TextBox1")。

Response.Redirect() 次の場合に使用する必要があります。

• リクエストをサーバー上のプレーンHTMLページまたは他のWebサーバーにリダイレクトしたい
• リクエストごとにサーバーへの追加のラウンドトリップが発生することは気にしません
• 元のリクエストのクエリ文字列とフォーム変数を保持する必要はありません
• ユーザーがブラウザでリダイレクトされる新しいリダイレクトURLを確認できるようにしたい（必要に応じてブックマークできるようにする）

Server.Transfer() 次の場合に使用する必要があります。

• 現在のページ要求を同じサーバー上の別の.aspxページに転送したい
• サーバーリソースを保持し、サーバーへの不要なラウンドトリップを回避したい
• クエリ文字列とフォーム変数を保持したい（オプション）
• ユーザーのWebブラウザーでリクエストをリダイレクトした実際のURLを表示する必要はありません

Response.Redirectは、最初のページがクライアントに到着した後で、ページを別のページにリダイレクトします。したがって、クライアントはリダイレクトを知っています。

Server.Transferは、ページの現在の実行を終了します。クライアントはリダイレクトを知りません。クエリ文字列とフォーム変数を転送できます。

したがって、どちらがより良いかを選択する必要性に依存します。

「response.redirect」と「server.transfer」は、ページの実行中にユーザーをあるページから別のページに転送するのに役立ちます。ただし、この転送/リダイレクトの方法は大きく異なります。

あなたが視覚的な人であり、理論ではなくデモンストレーションを見たい場合、私は、より実証的な方法で違いを説明する以下のFacebookのビデオを見るようにお勧めします。

https://www.facebook.com/photo.php?v=762186150488997

両者の主な違いは、誰が転送を行うかです。「response.redirect」では、転送はブラウザによって行われますが、「server.transfer」では、サーバーによって行われます。このステートメントをより詳細に理解してみましょう。

「Server.Transfer」では、転送がどのように行われるかを以下に示します。

1.ユーザーがASP.NETページにリクエストを送信します。下の図では、リクエストが「WebForm1」に送信され、「Webform2」に移動したいと思います。

2.サーバーが「Webform1」の実行を開始し、ページのライフサイクルが開始されます。しかし、ページの完全なライフサイクルが完了する前に、「WebForm2」に「Server.transfer」が発生します。

3.「Webform2」ページオブジェクトが作成され、全ページライフサイクルが実行され、出力HTML応答がブラウザに送信されます。

"Response.Redirect"の間、ナビゲーションのための一連のイベントは次のとおりです。

1.クライアント（ブラウザ）がリクエストをページに送信します。下の図では、リクエストが「WebForm1」に送信され、「Webform2」に移動したいと思います。

2.「Webform1」のライフサイクルが実行されます。しかし、ライフサイクルの間に "Response.Redirect"が発生します。

3.サーバーがリダイレクトを行う代わりに、HTTP 302コマンドをブラウザーに送信します。このコマンドは、 "Webform2.aspx"ページへのGET要求を開始する必要があることをブラウザーに通知します。

4.Browserは302コマンドを解釈し、「Webform2.aspx」のGETリクエストを送信します。

言い換えると、「Server.Transfer」はサーバーによって実行され、「Response.Redirect」はブラウザーによって実行されます。「Response.Redirect」は、ページのリダイレクトを行うために2つの要求を行う必要があります。

では、「Server.Transfer」をいつ使用し、「Response.Redirect」をいつ使用するのでしょうか。

同じサーバー上にあるページ間を移動する場合は「Server.Transfer」を使用し、異なるサーバーおよびドメイン上にあるページ間を移動する場合は「Response.Redirect」を使用します。

以下は、違いを明確にし、どのシナリオを使用するかをまとめた表です。

Server.Transferの美しさは、それを使ってできることです。

TextBox myTxt = (TextBox)this.Page.PreviousPage.FindControl("TextBoxID");

Server.Transferを使用してResponse.Redirectを使用しない限り、上記の方法を使用して前のページから何でも取得できます。

ScarletGardenのコメントに加えて、検索エンジンとリダイレクトの影響も考慮する必要があります。このページは永久に移動しましたか？一時的に？それは違いを生みます。

参照：Response.Redirectと「301完全に移動」：

私たちは全員、一度にResponse.Redirectを使用しました。これは、訪問者が何らかの理由で間違った場所に到達した場合に、訪問者を正しい方向に向けさせる迅速かつ簡単な方法です。しかし、本当に「301 Moved Permanently」を送信したい場合に、Response.Redirectが「302 Found」のHTTP応答ステータスコードを送信することをご存知でしたか？

違いは小さいように見えますが、場合によっては実際に大きな違いを生む可能性があります。たとえば、「301 Moved Permanently」レスポンスコードを使用すると、ほとんどの検索エンジンは古いリンクをインデックスから削除し、新しいリンクに置き換えます。「302 Found」を使用すると、引き続き古いページに戻ります...

転送は完全にサーバー側です。クライアントのアドレスバーは一定のままです。リクエスト間のコンテキストの転送に関する複雑さ。ページハンドラーのフラッシュと再起動はコストがかかる可能性があるため、パイプラインの早い段階（たとえば、BeginRequest中のHttpModuleなど）で転送を行います。MSDNドキュメントを注意深く読み、HttpContext.Requestの新しい値をテストして理解してください-特にポストバックのシナリオでは。通常、エラーシナリオにはServer.Transferを使用します。

Redirectはリクエストを302ステータスで終了し、クライアント側の往復応答で例外を内部で処理します（マイナーサーバーパフォーマンスヒット-1日の実行回数によって異なります）クライアントは新しいアドレスに移動します。ブラウザのアドレスバーや履歴の更新など。クライアントは追加の往復の費用を支払います-費用は待ち時間によって異なります。私たちのビジネスでは、例外コストを回避するために独自のモジュールを作成して多くのリダイレクトを行っています。

上記のように多くの違いがあります。何よりも、もう1つ違いがあります。Response.Redirect()アプリケーションの一部ではない任意のページにユーザーをリダイレクトするためServer.Transfer()に使用できますが、アプリケーション内でユーザーをリダイレクトするためにのみ使用できます。

//This will work.
Response.Redirect("http://www.google.com");

//This will not work.
Server.Transfer("http://www.google.com");

Response.Redirectは、サーバーへの余分なトリップを追加してどこに行くべきかを判断するため、よりコストがかかります。

Server.Transferの方が効率的ですが、URLが物理的に変更されないため、ユーザーに誤解を与える可能性があります。

私の経験では、パフォーマンスの違いは、後者のアプローチを使用するには十分ではありませんでした

Server.TransferはクライアントブラウザーのURLを変更しないため、事実上、ブラウザーは別のサーバー側ハンドラーに変更されたことを認識しません。Response.Redirectはブラウザに別のページに移動するように指示するため、タイトルバーのURLが変更されます。

Server.Transferは、サーバーへの1回のラウンドトリップを回避するため、少し高速ですが、URLを変更しないことは、実行しようとしていることに応じて、良い場合も悪い場合もあります。

Response.Redirect：要求されたページが新しい場所にあることをブラウザに通知します。次に、ブラウザは新しいページへの別のリクエストを開始し、そのコンテンツをブラウザにロードします。これにより、ブラウザから2つの要求が出されます。

Server.Transfer：サーバーの最初のページから2番目のページに実行を転送します。ブラウザクライアントに関する限り、それは1つの要求を行い、最初のページはコンテンツで応答するページです。このアプローチの利点は、クライアントブラウザーからサーバーへのラウンドトリップが1つ少なくなることです。また、投稿されたフォーム変数とクエリ文字列パラメーターは、2番目のページでも使用できます。

Transfer（）の詳細については、実際にはServer.Execute（）+ Response.End（）であり、そのソースコードは以下のとおりです（Mono / .net 4.0から）。

public void Transfer (string path, bool preserveForm)
{
    this.Execute (path, null, preserveForm, true);
    this.context.Response.End ();
}

Execute（）の場合、実行されるのは指定されたパスのハンドラーです。

ASP.NETは、現在のユーザーがExecuteメソッドによって配信されたリソースを表示する権限を持っていることを確認しません。ASP.NETの承認と認証のロジックは元のリソースハンドラーが呼び出される前に実行されますが、ASP.NETはExecuteメソッドで指定されたハンドラーを直接呼び出し、新しいリソースの認証と承認のロジックは再実行しません。アプリケーションのセキュリティポリシーにより、クライアントがリソースにアクセスするための適切な承認を必要とする場合、アプリケーションは再承認を強制するか、カスタムのアクセス制御メカニズムを提供する必要があります。

Executeメソッドの代わりにRedirectメソッドを使用して、再認証を強制できます。Redirectは、ブラウザーが新しいリソースを要求するクライアント側リダイレクトを実行します。このリダイレクトはシステムに入る新しい要求であるため、インターネットインフォメーションサービス（IIS）とASP.NETセキュリティポリシーの両方のすべての認証および承認ロジックの影響を受けます。

- MSDNから

Response.Redirectは追加のラウンドトリップを含み、アドレスバーを更新します。

Server.Transferはアドレスバーを変更せず、サーバーは別のページのコンテンツでリクエストに応答します

例えば

Response.Redirect：-

1. クライアント上でブラウザがページhttp：//InitiallyRequestedPage.aspxをリクエストします
2. サーバーでは、リダイレクトアドレスhttp：//AnotherPage.aspxを渡して302でリクエストに応答します。
3. クライアント上で、ブラウザーはアドレスhttp：//AnotherPage.aspxに 2番目の要求を行います。
4. サーバー上でhttp：//AnotherPage.aspxからのコンテンツで応答します

Server.Transfer：-

1. クライアントブラウザでページhttp：//InitiallyRequestedPage.aspxを要求します。
2. サーバーServer.Transferでhttp：//AnotherPage.aspxに
3. サーバーでは、応答は要求に行われる//InitiallyRequestedPage.aspxます：httpから渡しバックコンテンツのhttp：//AnotherPage.aspx

Response.Redirect

長所： -RESTful-アドレスバーを変更します。アドレスを使用して、リクエスト間の状態の変化を記録できます。

短所：- 遅い-クライアントとサーバーの間の余分な往復があります。クライアントとサーバーの間にかなりの待ち時間がある場合、これは高価になる可能性があります。

Server.Transfer

長所：- クイック。

短所： -失われた状態-ポストバックに応じてServer.Transferを使用してアプリケーションの状態を変更している場合、ページがリロードされると、アドレスバーは以前と同じになるため、その状態は失われます。最初のリクエストで。

Response.Redirect Response.Redirect（）は、新しいページに移動し、アドレスバーを更新して、ブラウザの履歴に追加します。ブラウザで戻るをクリックできます。リクエストをサーバー上のプレーンHTMLページまたは他のWebサーバーにリダイレクトします。リクエストごとにサーバーへの追加のラウンドトリップが発生します。元のリクエストのクエリ文字列とフォーム変数は保持されません。これにより、ブラウザーでリダイレクトされた新しいリダイレクトURLを確認できます（必要な場合はブックマークに追加できます）。応答。リダイレクトは、メッセージを（HTTP 302）ブラウザーに送信するだけです。

Server.Transfer Server.Transfer（）はアドレスバーを変更しないので、戻ることはできません。ユーザーがどこに行くのかをユーザーに見せたくない場合は、Server.Transfer（）を使用する必要があります。「読み込み中」タイプのページが表示されることがあります。現在のページ要求を同じサーバー上の別の.aspxページに転送します。サーバーリソースを保持し、サーバーへの不要なラウンドトリップを回避します。クエリ文字列とフォーム変数を保持します（オプション）。ユーザーのWebブラウザーで要求をリダイレクトする実際のURLは表示されません。Server.Transferは、ブラウザーが何も知らずに発生し、ブラウザーはページを要求しますが、サーバーは別のページのコンテンツを返します。