Server.Transfer Vs. Response.Redirect

Response.Redirect() отправит вас на новую страницу, обновит адресную строку и добавит ее в историю браузера. В вашем браузере вы можете нажать кнопку "назад".

Server.Transfer() не изменяет адресную строку. Вы не можете ударить.

Я использую Server.Transfer(), когда я не хочу, чтобы пользователь видел, куда я иду. Иногда на странице типа загрузки.

В противном случае я всегда буду использовать Response.Redirect().

Быть коротким: Response.Redirect просто сообщает браузеру перейти на другую страницу. Server.Transfer помогает уменьшить запросы на сервер, сохраняет URL-адрес одинаково и, с небольшим количеством ошибок, позволяет передавать строку запроса и формы переменных.

Что-то я нашел и согласен с (source):

Server.Transfer аналогичен тому, что он отправляет пользователя на другую страницу с утверждением типа Server.Transfer("WebForm2.aspx"). Однако, утверждение имеет ряд очевидных преимуществ и недостатков.

Во-первых, переход на другую страницу с помощью Server.Transferсохраняет ресурсы сервера. Вместо того, чтобы сообщать браузеру перенаправлять, он просто меняет "фокус" на веб-сервере и передает запрос. Это означает, что вы не получаете столько же HTTP запросы, которые, таким образом, облегчают Веб-сервер и ускоряет выполнение ваших приложений.

Но будьте осторожны: потому что процесс "передачи" может работать только на тех сайты, запущенные на сервере; вы не можете использовать Server.Transfer для отправки пользователь на внешний сайт. Только Response.Redirect может это сделать.

Во-вторых, Server.Transfer поддерживает исходный URL-адрес в браузере. Это может действительно помочь упростить методы ввода данных, хотя это может сделать путаницу при отладке.

Это не все: метод Server.Transfer также имеет второй параметрируемый "preserveForm". Если вы установите значение True, используя оператор например Server.Transfer("WebForm2.aspx", True), существующий запрос строка и любые переменные формы будут по-прежнему доступны для вас переносятся на.

Например, если ваш WebForm1.aspx имеет элемент управления TextBox, называемый TextBox1, и вы перешли в WebForm2.aspx с сохранением формы установите значение True, вы сможете получить значение исходная страница Управление TextBox путем ссылки Request.Form("TextBox1").

Отклик. Переадресация перенаправляет страницу на другую страницу после. Поэтому клиент знает перенаправление.

Server.Transfer завершает текущее выполнение страницы. Клиент не знает перенаправления. Он позволяет передавать строку запроса и формировать переменные.

Таким образом, это зависит от ваших потребностей, которые лучше выбирать.

Response.Redirect() следует использовать, когда:

• мы хотим перенаправить запрос на некоторые простые HTML-страницы на нашем сервере или на какой-либо другой веб-сервер.
• мы не заботимся о том, чтобы вызвать дополнительные обратные вызовы на сервер по каждому запросу
• нам не нужно сохранять строки запроса и переменные формы из исходного запроса
• мы хотим, чтобы наши пользователи могли видеть новый перенаправленный URL-адрес, где он перенаправлен в своем браузере (и иметь возможность добавлять его в закладки, если это необходимо)

Server.Transfer() следует использовать, когда:

• мы хотим перенести текущий запрос страницы на другую страницу .aspx на том же сервере
• мы хотим сохранить ресурсы сервера и избежать ненужных обращений к серверу
• мы хотим сохранить Query String и Form Variables (необязательно)
• нам не нужно показывать реальный URL-адрес, где мы перенаправили запрос в веб-браузере пользователей

"response.redirect" и "server.transfer" помогает переносить пользователя с одной страницы на другую страницу во время выполнения страницы. Но то, как они делают эту передачу/перенаправление, сильно отличается.

В случае, если вы являетесь визуальным парнем и хотите увидеть демонстрацию, а не теорию, я бы предложил посмотреть нижеприведенное видео в facebook, которое объясняет разницу в более показательном виде.

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

Основное различие между ними - кто делает передачу. В "response.redirect" передача выполняется браузером, а в "server.transfer" - его завершение сервером. Давайте попробуем понять это утверждение более подробно.

В "Server.Transfer" следуют последовательность передачи: -

1.User отправляет запрос на страницу ASP.NET. На следующем рисунке запрос отправляется в "WebForm1", и мы хотели бы перейти к "Webform2" .

2. Сервер запускает "Webform1", и начинается жизненный цикл страницы. Но до завершения полного жизненного цикла страницы "Server.transfer" происходит с "WebForm2".

3. Создается объект страницы "Webform2" , выполняется полный жизненный цикл страницы и затем отправляется HTML-запрос в браузер.

В разделе "Response.Redirect" следуют последовательность событий для навигации: -

1.Client(браузер) отправляет запрос на страницу. На следующем рисунке запрос отправляется в "WebForm1", и мы хотели бы перейти к "Webform2" .

2. Запуск цикла "Webform1" начинается. Но между жизненным циклом происходит "Response.Redirect" .

3.Не вместо сервера, выполняющего перенаправление, он отправляет в браузер команду HTTP 302. Эта команда сообщает браузеру, что он должен инициировать запрос GET на страницу "Webform2.aspx".

4.Browser интерпретирует команду 302 и отправляет запрос GET для "Webform2.aspx".

Другими словами, сервер Server.Transfer выполняется сервером, а "Response.Redirect" выполняется браузером thr. "Response.Redirect" требует двух запросов для перенаправления страницы.

Итак, когда использовать "Server.Transfer" и когда использовать "Response.Redirect" ?

Используйте "Server.Transfer" , когда вы хотите перемещаться по страницам, которые находятся на одном сервере, используйте "Response.Redirect" , если вы хотите перемещаться между страницами, которые находятся на разных серверах и доменах.

Ниже приведена сводная таблица, в которой перечислены различия и в каком сценарии использовать.

В дополнение к комментарию ScarletGarden вам также необходимо рассмотреть влияние поисковых систем и вашего перенаправления. Постоянно ли эта страница перемещалась? Временно? Это имеет значение.

см. Response.Redirect vs. "301 Перемещено на постоянной основе" :

Мы все использовали Response.Redirect на в одно и то же время. Это быстрый и простой способ заставить посетителей указать в правильном направлении, если они каким-то образом в конечном итоге не в том месте. Но вы знайте, что Response.Redirect отправляет Код состояния HTTP-ответа "302 Найдено", когда вы действительно захотите отправить "301 перемещен навсегда"?

Различие кажется небольшим, но в в некоторых случаях он может фактически сделать большая разница. Например, если вы используйте ответ "301 Moved Permently" кода, большинство поисковых систем удалит устаревшее звено от их индекса и замените его на новый. если ты используйте "302 Найдено", они будут продолжаться возвращение на старую страницу...

Красота Server.Transfer - это то, что вы можете с ней сделать:

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

Вы можете получить что-либо со своей предыдущей страницы, используя указанный выше метод, если вы используете Server.Transfer, но не Response.Redirect

Перевод полностью серверный. Панель адресов клиентов остается постоянной. Некоторая сложность передачи контекста между запросами. Промывка и перезапуск обработчиков страниц может быть дорогостоящим, поэтому перенос в начале пути, например, в HttpModule во время BeginRequest. Внимательно прочитайте документы MSDN и проверьте и ознакомьтесь с новыми значениями HttpContext.Request - особенно в сценариях Postback. Обычно мы используем Server.Transfer для сценариев ошибок.

Redirect завершает запрос с состоянием 302 и ответным обратным вызовом на стороне клиента и внутренне ест исключение (незначительный серверный перфоманс - зависит от того, сколько вы делаете в день). Затем клиент переходит к новому адресу. Браузерная адресная строка и обновления истории и т.д. Клиент оплачивает стоимость дополнительного тура - стоимость варьируется в зависимости от латентности. В нашем бизнесе мы перенаправляем много, мы написали собственный модуль, чтобы избежать стоимости исключения.

Response.Redirect более дорогостоящий, поскольку он добавляет дополнительную поездку на сервер, чтобы выяснить, куда идти.

Server.Transfer более эффективен, однако он может быть немного неправильным для пользователя, так как Url физически не изменяется.

По моему опыту, разница в производительности не была достаточно значительной, чтобы использовать последний подход

Response.Redirect: сообщает браузеру, что запрашиваемая страница может быть найдена в новом месте. Затем браузер инициирует другой запрос на новую страницу, загружая ее содержимое в браузере. Это приводит к двум запросам браузера.

Server.Transfer: Он переносит выполнение с первой страницы на вторую страницу на сервере. Что касается клиента браузера, он сделал один запрос, а на первой странице отвечает тот, кто отвечает содержимым. Преимущество этого подхода - однократное путешествие на сервер от браузера клиента. Кроме того, любые опубликованные переменные формы и параметры строки запроса доступны и для второй страницы.

Server.Transfer не изменяет URL-адрес в браузере клиента, поэтому браузер не знает, что вы перешли на другой серверный обработчик. Response.Redirect сообщает браузеру перейти на другую страницу, поэтому URL-адрес в заголовке изменится.

Server.Transfer работает немного быстрее, так как он избегает одного обратного перехода к серверу, но не изменение URL-адреса может быть хорошим или плохим для вас, в зависимости от того, что вы пытаетесь сделать.

Подробнее о 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, и не перезапускает логику аутентификации и авторизации для нового ресурса. Если для политики безопасности приложения требуется, чтобы клиенты имели соответствующее разрешение для доступа к ресурсу, приложение должно принудительно выполнить повторную авторизацию или предоставить настраиваемый механизм контроля доступа.

Вы можете принудительно выполнить повторную авторизацию с использованием метода Redirect вместо метода Execute. Redirect выполняет перенаправление на стороне клиента, в котором браузер запрашивает новый ресурс. Поскольку это перенаправление - это новый запрос, входящий в систему, он подвергается всей логике аутентификации и авторизации как политики Internet Information Services (IIS), так и политики безопасности ASP.NET.

- из MSDN

Клиент Server.Transfer(): отображается так, как он есть только на запрашивающей странице, но все содержимое запрашиваемой страницы. Данные могут сохраняться на страницах, используя коллекцию Context.Item, которая является одним из лучших способов переноса данных с одной страницы на другую, сохраняя состояние страницы.

Клиент Response.Redirect(): знает физическое местоположение (название страницы и строку запроса). Context.Items теряет устойчивость при переходе к целевой странице. В более ранних версиях IIS, если бы мы хотели отправить пользователя на новую веб-страницу, единственным вариантом, который у нас был, был Response.Redirect. Хотя этот метод и позволяет достичь нашей цели, он имеет несколько важных недостатков. Самая большая проблема заключается в том, что этот метод заставляет каждую страницу рассматриваться как отдельная транзакция. Помимо затруднения для поддержания целостности транзакций, Response.Redirect вводит некоторые дополнительные головные боли. Во-первых, это предотвращает хорошую инкапсуляцию кода. Во-вторых, вы теряете доступ ко всем свойствам объекта Request. Конечно, есть обходные пути, но они сложны. Наконец, Response.Redirect требует поездки в оба конца клиенту, что на крупных узлах вызывает проблемы с масштабируемостью.

• Так же, как гиперссылка и Response.Redirect, Server.Transfer используется для перехода на другие страницы/сайты, запущенные на одном и том же веб-сервере.
• Server.Transfer не может использоваться для навигации по сайтам/страницам на другом веб-сервере.
• Server.Transfer не изменяет URL-адрес в адресной строке
• Server.Transfer быстрее, чем Response.Redirect, поскольку перенаправление происходит на сервере в одном цикле запроса/ответа. Response.Redirect() включает в себя 2 цикла запроса/ответа.
• С Server.Transfer сохраняются переменные формы из исходного запроса.

Существует много различий, как указано выше. Кроме того, есть еще одно отличие. Response.redirect() может использоваться для перенаправления пользователя на любую страницу, которая не является частью приложения, но server.transfer() может использоваться только для перенаправления пользователя в приложении.

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

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

Response.Redirect Response.Redirect() отправит вас на новую страницу, обновит адресную строку и добавит ее в историю браузера. В вашем браузере вы можете нажать "Назад". Он перенаправляет запрос на некоторые простые HTML-страницы на нашем сервере или на какой-либо другой веб-сервер. Это вызывает дополнительные обратные вызовы для сервера по каждому запросу. Он не сохраняет Query String и Form Variables из исходного запроса. Он позволяет видеть новый перенаправленный URL-адрес, где он перенаправляется в браузере (и иметь возможность добавлять его в закладки, если это необходимо). Отклик. Redirect просто отправляет сообщение в браузер (HTTP 302).

Server.Transfer Server.Transfer() не меняет адресную строку, мы не можем ударить назад. Один должен использовать Server.Transfer(), когда он/она не хочет, чтобы пользователь видел, куда он идет. Когда-нибудь на странице типа загрузки. Он переносит текущий запрос страницы на другую страницу .aspx на том же сервере. Он сохраняет ресурсы сервера и избегает ненужных обращений к серверу. Он сохраняет строки запроса и формы (необязательно). Он не показывает реальный URL-адрес, где он перенаправляет запрос в веб-браузере пользователей. Server.Transfer происходит без браузера, зная что-либо, браузер запрашивает страницу, но сервер возвращает содержимое другого.

Response.Redirect включает дополнительную поездку в оба конца и обновляет адресную строку.

Server.Transfer не приводит к изменению адресной строки, сервер отвечает на запрос с содержимым с другой страницы

например.

Response.Redirect: -

• На клиенте браузер запрашивает страницу http://InitiallyRequestedPage.aspx
• На сервере отвечает запрос с адресом 302, передающим адрес переадресации http://AnotherPage.aspx.
• На клиенте браузер делает второй запрос по адресу http://AnotherPage.aspx.
• На сервере отвечает контент из http://AnotherPage.aspx

Server.Transfer: -

• В браузере клиента запрашивается страница http://InitiallyRequestedPage.aspx
• На сервере Server.Transfer to http://AnotherPage.aspx
• На сервере ответ делается на запрос http://InitiallyRequestedPage.aspx передачи содержимого из http://AnotherPage.aspx

Response.Redirect

Плюсы: - RESTful - он изменяет адресную строку, адрес может использоваться для записи изменений состояния между запросами.

Минусы: - Медленный - между клиентом и сервером есть дополнительный раунд. Это может быть дорогостоящим, когда между клиентом и сервером существует существенная латентность.

Server.Transfer

Плюсы: - Быстрый.

Минусы: - State lost - Если вы используете Server.Transfer для изменения состояния приложения в ответ на обратную связь, если страница перезагружается, состояние будет потеряно, так как адресная строка будет такой же, как и на первой запрос.