У чому різниця між Server.Transfer
і Response.Redirect
?
- Які переваги та недоліки кожного?
- Коли одна доречна над іншою?
- Коли один не підходить?
Server.TransferRequest
замість Server.Transfer
.
У чому різниця між Server.Transfer
і Response.Redirect
?
Server.TransferRequest
замість Server.Transfer
.
Відповіді:
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
збереження ресурсів сервера. Замість того, щоб казати браузеру переспрямовувати, він просто змінює «фокус» на веб-сервері та передає запит. Це означає, що ви не отримуєте так багато запитів HTTP, що, таким чином, полегшує тиск на ваш веб-сервер і робить ваші програми швидшими.Але будьте уважні: адже процес "передачі" може працювати лише на тих сайтах, які працюють на сервері; ви не можете використовувати
Server.Transfer
для відправки користувача на зовнішній сайт. Тільки цеResponse.Redirect
можна зробити.По-друге,
Server.Transfer
підтримує оригінальну URL-адресу в браузері. Це дійсно може допомогти впорядкувати методи введення даних, хоча це може створити плутанину при налагодженні.Це ще не все: у
Server.Transfer
методу також є другий параметр - "saveForm". Якщо встановити цеTrue
, використовуючи такий оператор, якServer.Transfer("WebForm2.aspx", True)
, наприклад , наявний рядок запиту та будь-які змінні форми, як і раніше, будуть доступні для сторінки, на яку ви переходите.Наприклад, якщо у вашому WebForm1.aspx є елемент управління TextBox під назвою TextBox1, і ви перейшли до WebForm2.aspx з параметром saveForm, встановленим на True, ви зможете отримати значення вихідної сторінки управління TextBox шляхом посилання
Request.Form("TextBox1")
.
maintaining the original URL... ...really help streamline data entry techniques
?
Response.Redirect()
слід використовувати, коли:
Server.Transfer()
слід використовувати, коли:
Response.Redirect перенаправляє сторінку на іншу сторінку після того, як перша сторінка надійде до клієнта. Тож клієнт знає перенаправлення.
Server.Transfer закриває поточне виконання сторінки. Клієнт не знає перенаправлення. Це дозволяє передавати рядок запиту та формувати змінні.
Тож залежить від ваших потреб вибрати, який краще.
Response.Redirect
так, щоб завантажити оригінальну сторінку, навіть якщо я зателефонував Response.Redirect
?
"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" і починається життєвий цикл сторінки. Але до завершення повного життєвого циклу сторінки "Server.transfer" трапляється на "WebForm2".
3. Створюється об’єкт сторінки "Webform2", виконується повний життєвий цикл сторінки, після чого вихідний HTML-відповідь надсилається до браузера.
Перебуваючи в "Response.Redirect", наступна послідовність подій навігації: -
1.Клієнт (браузер) надсилає запит на сторінку. На малюнку нижче запит надсилається до "WebForm1", і ми хотіли б перейти до "Webform2".
2. Цикл життя "Webform1" починає виконуватися. Але між життєвим циклом трапляється "Response.Redirect".
3.Не замість того, як сервер робить переадресацію, він надсилає в браузер команду HTTP 302. Ця команда повідомляє браузеру, що він повинен ініціювати GET-запит на сторінку "Webform2.aspx".
4.Browser інтерпретує команду 302 та надсилає GET-запит на "Webform2.aspx".
Іншими словами, "Server.Transfer" виконується сервером, тоді як "Response.Redirect" виконується браузером. "Response.Redirect" потребує двох запитів, щоб зробити переадресацію сторінки.
Тож коли використовувати "Server.Transfer" і коли використовувати "Response.Redirect"?
Використовуйте "Server.Transfer", коли ви хочете переміщуватися по сторінках, які перебувають на одному сервері, використовуйте "Response.Redirect", коли ви хочете переходити між сторінками, які знаходяться на іншому сервері та домені.
Нижче наведена зведена таблиця, яка визначає відмінності та в якому сценарії використовувати.
Server.Transfer
: того самого сервера чи того ж веб-сайту IIS ?
Краса Server.Transfer - це те, що ви можете зробити з цим:
TextBox myTxt = (TextBox)this.Page.PreviousPage.FindControl("TextBoxID");
Ви можете отримати що-небудь із попередньої сторінки, використовуючи вищевказаний метод, якщо ви використовуєте Server.Transfer, але не Response.Redirect
Окрім коментаря ScarletGarden, вам також потрібно врахувати вплив пошукових систем та ваше переадресація. Чи переміщена ця сторінка назавжди? Тимчасово? Це має значення.
дивіться: Response.Redirect vs. "301 Переміщено постійно" :
Всі ми використовували Response.Redirect в той чи інший час. Це швидкий і простий спосіб орієнтувати відвідувачів у правильному напрямку, якщо вони якимось чином опиняються в неправильному місці. Але чи знаєте ви, що Response.Redirect надсилає код статусу відповіді HTTP "302 знайдено", коли ви, можливо, хочете надіслати "301 переміщений постійно"?
Відмінність здається невеликою, але в певних випадках вона насправді може мати велике значення. Наприклад, якщо ви використовуєте код відповіді "301 переміщений постійно", більшість пошукових систем видалить застаріле посилання зі свого індексу та замінить його новим. Якщо ви використовуєте "302 знайдено", вони продовжать повертатися на стару сторінку ...
Передача повністю на сервері. Рядок адреси клієнта залишається постійним. Певна складність щодо передачі контексту між запитами. Промивання та перезапуск обробників сторінок може бути дорогим, тому перенесіть рано на конвеєр, наприклад, у HttpModule під час BeginRequest. Уважно прочитайте документи MSDN та протестуйте та розумійте нові значення HttpContext.Request - особливо в сценаріях Postback. Ми зазвичай використовуємо Server.Transfer для сценаріїв помилок.
Перенаправлення припиняє запит зі статусом 302 і відповідь на зворотній стороні клієнта, і внутрішньо з'їдає виняток (незначне потрапляння сервера на перф - залежить від кількості за день) Клієнт переходить на нову адресу. Адресна панель веб-переглядача та оновлення історії тощо. Клієнт оплачує додатковий перехід - вартість варіюється в залежності від затримки. У нашому бізнесі ми багато переадресуємо, ми написали власний модуль, щоб уникнути вартості виключень.
Існує багато відмінностей, як зазначено вище. Крім передусім, є ще одна відмінність. 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 трохи швидше, оскільки він дозволяє уникнути одного переходу на сервер, але незміна URL-адреси може бути для вас добрим чи поганим, залежно від того, що ви намагаєтеся зробити.
Response.Redirect: повідомляє веб-переглядачу, що запитувана сторінка може бути знайдена в новому місці. Потім браузер ініціює інший запит на нову сторінку, завантажуючи її вміст у браузер. Це призводить до двох запитів браузера.
Server.Transfer: Він передає виконання з першої сторінки на другу сторінку на сервері. Що стосується клієнта браузера, він зробив один запит, а початкова сторінка - та, яка відповідає змістом. Перевага такого підходу - одна менш зворотна поїздка до сервера через клієнтський браузер. Також будь-які розміщені змінні форми та параметри рядка запиту також доступні для другої сторінки.
Ще детальніше про 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 виконує перенаправлення на стороні клієнта, в якому браузер запитує новий ресурс. Оскільки це перенаправлення є новим запитом, що надходить у систему, воно піддається всій логіці аутентифікації та авторизації як інформаційних служб Інтернету (IIS), так і політики безпеки ASP.NET.
- від MSDN
Response.Redirect передбачає додаткову подорож і оновлює адресний рядок.
Server.Transfer не призводить до зміни адресного рядка, сервер відповідає на запит вмістом з іншої сторінки
напр
Response.Redirect: -
Сервер.Трансфер: -
Response.Redirect
Плюси: - RESTful - Змінює адресний рядок, адресу можна використовувати для запису змін стану між запитами.
Мінуси: - Повільне - між клієнтом та сервером є додаткова поїздка. Це може бути дорогим, коли між клієнтом і сервером є значні затримки.
Server.Transfer
Плюси: - Швидкий.
Мінуси: - Загублено стан - Якщо ви використовуєте Server.Transfer для зміни стану програми у відповідь на звороти публікації, якщо сторінка буде перезавантажена, цей стан буде втрачено, оскільки адресний рядок буде таким самим, як був за першим запитом
Response.Redirect Response.Redirect () надішле вас на нову сторінку, оновить адресний рядок і додасть його до історії веб-переглядачів. У вашому браузері можна натиснути назад. Він перенаправляє запит на деякі звичайні HTML-сторінки на нашому сервері або на інший веб-сервер. Це викликає додаткові зворотні переходи до сервера при кожному запиті. Він не зберігає рядки запитів і змінних форм від початкового запиту. Це дозволяє бачити нову перенаправлену URL-адресу, куди вона переспрямована у веб-переглядачі (і мати можливість встановити закладку, якщо це необхідно). Відповідь. Перенаправлення просто надсилає повідомлення до браузера (HTTP 302).
Server.Transfer Server.Transfer () не змінює адресний рядок, ми не можемо повернути назад. Один повинен використовувати Server.Transfer (), коли він / вона не хоче, щоб користувач бачив, куди він йде. Десь на сторінці типу "завантаження". Він передає поточний запит на іншу сторінку .aspx на тому ж сервері. Він зберігає серверні ресурси та уникає зайвих зворотів на сервер. Він зберігає змінну рядка запиту та форми (необов'язково). Він не показує реальну URL-адресу, куди він перенаправляє запит у веб-переглядачі користувачів. Server.Transfer відбувається без того, що браузер нічого не знає, браузер запитує сторінку, але сервер повертає вміст іншого.