Server.Transfer vs. Odpowiedź. Przekierowanie

Jaka jest różnica między Server.Transferi Response.Redirect?

• Jakie są zalety i wady każdego z nich?
• Kiedy jedno jest odpowiednie w stosunku do drugiego?
• Kiedy ktoś nie jest odpowiedni?

Response.Redirectpo prostu wysyła wiadomość (HTTP 302) do przeglądarki.

Server.Transfer dzieje się bez wiedzy przeglądarki, przeglądarka żąda strony, ale serwer zwraca treść innej.

Response.Redirect()wyśle ​​cię na nową stronę, zaktualizuje pasek adresu i doda go do historii przeglądarki. W przeglądarce możesz kliknąć wstecz.

Server.Transfer()nie zmienia paska adresu. Nie możesz trafić.

Używam, Server.Transfer()gdy nie chcę, aby użytkownik widział, dokąd zmierzam. Czasami na stronie typu „ładowanie”.

W przeciwnym razie zawsze użyję Response.Redirect().

Mówiąc krótko: Response.Redirectpo prostu mówi przeglądarce, aby otworzyła inną stronę. Server.Transferpomaga zredukować liczbę żądań serwera, utrzymuje ten sam adres URL i, przy odrobinie błędów, pozwala przenieść ciąg zapytania i zmienne formularza.

Coś, co znalazłem i zgadzam się z ( źródło ):

Server.Transferjest podobny w tym sensie, że wysyła użytkownika na inną stronę z instrukcją, np Server.Transfer("WebForm2.aspx"). To stwierdzenie ma jednak wiele wyraźnych zalet i wad.

Po pierwsze, przeniesienie na inną stronę przy użyciu Server.Transfer oszczędza zasoby serwera. Zamiast nakazać przeglądarce przekierowanie, po prostu zmienia „skupienie” na serwerze sieciowym i przesyła żądanie. Oznacza to, że nie otrzymujesz tylu żądań HTTP, co zmniejsza obciążenie serwera WWW i przyspiesza działanie aplikacji.

Ale uważaj: ponieważ proces „transferu” może działać tylko na tych stronach, które działają na serwerze; nie można użyć Server.Transferdo wysłania użytkownika do witryny zewnętrznej. Tylko Response.Redirectmoże to zrobić.

Po drugie, Server.Transferutrzymuje oryginalny adres URL w przeglądarce. Może to naprawdę pomóc w usprawnieniu technik wprowadzania danych, chociaż może powodować zamieszanie podczas debugowania.

To nie wszystko: Server.Transfermetoda ma również drugi parametr - „preserveForm”. Jeśli ustawisz to na True, używając instrukcji takiej jak Server.Transfer("WebForm2.aspx", True)istniejący ciąg zapytania i wszelkie zmienne formularza będą nadal dostępne dla strony, na którą przenosisz.

Na przykład, jeśli Twój plik WebForm1.aspx ma kontrolkę TextBox o nazwie TextBox1 i zostałeś przeniesiony do WebForm2.aspx z parametrem preserveForm ustawionym na True, będziesz mógł odzyskać wartość oryginalnej kontrolki TextBox strony poprzez odwołanie Request.Form("TextBox1").

Response.Redirect() należy stosować, gdy:

• chcemy przekierować żądanie na niektóre zwykłe strony HTML na naszym serwerze lub na inny serwer WWW
• nie dbamy o to, by na każde żądanie powodować dodatkowe okrążenia serwera
• nie musimy zachowywać ciągów zapytań i zmiennych formularzy z pierwotnego żądania
• chcemy, aby nasi użytkownicy mogli zobaczyć nowy przekierowany adres URL, pod którym jest przekierowywany w przeglądarce (i w razie potrzeby móc dodać go do zakładek)

Server.Transfer() należy stosować, gdy:

• chcemy przenieść bieżące żądanie strony na inną stronę .aspx na tym samym serwerze
• chcemy zachować zasoby serwera i uniknąć niepotrzebnych objazdów do serwera
• chcemy zachować ciąg zapytania i zmienne formularza (opcjonalnie)
• nie musimy pokazywać prawdziwego adresu URL, pod którym przekierowaliśmy żądanie w przeglądarce internetowej użytkownika

Response.Redirect przekierowuje stronę na inną stronę po przybyciu pierwszej strony do klienta. Tak więc klient zna przekierowanie.

Server.Transfer kończy bieżące wykonanie strony. Klient nie zna przekierowania. Pozwala przenieść ciąg zapytania i zmienne formularza.

To zależy od twoich potrzeb wyboru, który jest lepszy.

„response.redirect” i „server.transfer” pomaga przenieść użytkownika z jednej strony na drugą podczas wykonywania strony. Ale sposób, w jaki dokonują tego transferu / przekierowania, jest zupełnie inny.

Jeśli jesteś wizualnym facetem i wolisz zobaczyć demonstrację niż teorię, proponuję zobaczyć poniższy film na Facebooku, który wyjaśnia różnicę w bardziej demonstracyjny sposób.

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

Główną różnicą między nimi jest to, kto dokonuje transferu. W „response.redirect” transfer odbywa się w przeglądarce, natomiast w „server.transfer” serwer. Spróbujmy zrozumieć to stwierdzenie w bardziej szczegółowy sposób.

W „Server.Transfer” następująca sekwencja jest następująca:

1. Użytkownik wysyła żądanie do strony ASP.NET. Na poniższym rysunku żądanie jest wysyłane do „WebForm1” i chcielibyśmy przejść do „Webform2”.

2. Serwer rozpoczyna wykonywanie „Webform1” i rozpoczyna się cykl życia strony. Ale przed zakończeniem pełnego cyklu życia strony „Server.transfer” dzieje się z „WebForm2”.

3. Tworzony jest obiekt strony „Webform2”, wykonywany jest pełny cykl życia strony, a następnie wyjściowa odpowiedź HTML jest wysyłana do przeglądarki.

W „Response.Redirect” poniżej znajduje się sekwencja zdarzeń do nawigacji: -

1. Klient (przeglądarka) wysyła żądanie do strony. Na poniższym rysunku żądanie jest wysyłane do „WebForm1” i chcielibyśmy przejść do „Webform2”.

2. Cykl życia „Webform1” zaczyna się uruchamiać. Ale pomiędzy cyklem życia zdarza się „Response.Redirect”.

3. Teraz zamiast przekierowywania serwer wysyła do przeglądarki polecenie HTTP 302. To polecenie informuje przeglądarkę, że musi zainicjować żądanie GET na stronie „Webform2.aspx”.

4.Browser interpretuje polecenie 302 i wysyła żądanie GET dla „Webform2.aspx”.

Innymi słowy „Server.Transfer” jest wykonywany przez serwer, podczas gdy „Response.Redirect” jest wykonywany przez przeglądarkę. „Response.Redirect” wymaga dwóch próśb o przekierowanie strony.

Kiedy więc użyć „Server.Transfer”, a kiedy „Response.Redirect”?

Użyj „Server.Transfer”, jeśli chcesz nawigować po stronach znajdujących się na tym samym serwerze, użyj „Response.Redirect”, jeśli chcesz nawigować między stronami, które znajdują się na innym serwerze i domenie.

Poniżej znajduje się tabela podsumowująca, która przedstawia różnice i w którym scenariuszu zastosować.

Piękno Server.Transfer możesz z tym zrobić:

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

Możesz uzyskać wszystko z poprzedniej strony przy użyciu powyższej metody, o ile korzystasz z Server.Transfer, ale nie Response.Redirect

Oprócz komentarza ScarletGarden należy także wziąć pod uwagę wpływ wyszukiwarek i przekierowania. Czy ta strona została przeniesiona na stałe? Tymczasowo? To robi różnicę.

patrz: Response.Redirect vs. „301 Moved Permanently” :

Wszyscy kiedyś korzystaliśmy z Response.Redirect. Jest to szybki i łatwy sposób na skierowanie odwiedzających we właściwym kierunku, jeśli znajdą się w niewłaściwym miejscu. Ale czy wiesz, że Response.Redirect wysyła kod stanu odpowiedzi HTTP „Znaleziono 302”, kiedy naprawdę możesz chcieć wysłać „301 przeniesiony na stałe”?

Różnica wydaje się niewielka, ale w niektórych przypadkach może mieć naprawdę duże znaczenie. Na przykład, jeśli użyjesz kodu odpowiedzi „301 Moved Permanently”, większość wyszukiwarek usunie przestarzały link ze swojego indeksu i zastąpi go nowym. Jeśli użyjesz „Znaleziono 302”, nadal będą wracać do starej strony ...

Transfer odbywa się całkowicie po stronie serwera. Pasek adresu klienta pozostaje stały. Pewna złożoność związana z przenoszeniem kontekstu między żądaniami. Opróżnianie i ponowne uruchamianie procedur obsługi stron może być kosztowne, więc zrób transfer na początku rurociągu, np. W module HttpModu podczas BeginRequest. Przeczytaj uważnie dokumenty MSDN oraz przetestuj i zrozum nowe wartości HttpContext.Request - szczególnie w scenariuszach Postback. Zazwyczaj używamy Server.Transfer do scenariuszy błędów.

Przekierowanie kończy żądanie ze statusem 302 i odpowiedzią w obie strony po stronie klienta i wewnętrznie zjada wyjątek (drobne trafienie serwera - zależy od tego, ile robisz dziennie). Klient następnie przechodzi do nowego adresu. Pasek adresu przeglądarki i aktualizacje historii itp. Klient pokrywa koszt dodatkowej podróży w obie strony - koszt zależy od opóźnienia. W naszej działalności często przekierowujemy , napisaliśmy własny moduł, aby uniknąć kosztów wyjątków.

Istnieje wiele różnic określonych powyżej. Oprócz przede wszystkim jest jeszcze jedna różnica. Response.Redirect()może być użyty do przekierowania użytkownika na dowolną stronę, która nie jest częścią aplikacji, ale Server.Transfer()może być użyty tylko do przekierowania użytkownika w aplikacji.

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

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

Odpowiedź.Redirect jest bardziej kosztowny, ponieważ dodaje dodatkową podróż do serwera, aby dowiedzieć się, gdzie iść.

Server.Transfer jest bardziej wydajny, jednak może być nieco mylący dla użytkownika, ponieważ adres URL nie zmienia się fizycznie.

Z mojego doświadczenia wynika, że ​​różnica w wydajności nie była wystarczająco znacząca, aby zastosować to drugie podejście

Server.Transfer nie zmienia adresu URL w przeglądarce klienta, więc w rzeczywistości przeglądarka nie wie, że zmieniłeś się na inny moduł obsługi po stronie serwera. Odpowiedź Odpowiedź przekierowuje przeglądarkę na przejście na inną stronę, więc zmienia się adres URL na pasku tytułowym.

Server.Transfer jest nieco szybszy, ponieważ pozwala uniknąć jednej podróży do serwera, ale brak zmiany adresu URL może być dla ciebie dobry lub zły, w zależności od tego, co próbujesz zrobić.

Odpowiedź: Przekierowanie: informuje przeglądarkę, że żądaną stronę można znaleźć w nowej lokalizacji. Przeglądarka następnie inicjuje kolejne żądanie do nowej strony ładującej jej zawartość w przeglądarce. Powoduje to dwa żądania przeglądarki.

Server.Transfer: Przenosi wykonanie z pierwszej strony na drugą stronę na serwerze. Jeśli chodzi o klienta przeglądarki, wysłał jedno żądanie, a strona początkowa odpowiada stroną z treścią. Zaletą tego podejścia jest o jedną podróż w obie strony do serwera z przeglądarki klienta. Ponadto wszelkie zmienne formularza i parametry ciągu zapytania są dostępne również na drugiej stronie.

Jeszcze więcej szczegółów na temat Transfer (), tak naprawdę jest to Server.Execute () + Response.End (), jego kod źródłowy znajduje się poniżej (z Mono / .net 4.0):

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

a dla Execute () to, co należy uruchomić, to moduł obsługi podanej ścieżki, patrz

ASP.NET nie weryfikuje, czy bieżący użytkownik jest uprawniony do przeglądania zasobu dostarczonego metodą Wykonaj . Chociaż logika autoryzacji i uwierzytelniania ASP.NET działa przed wywołaniem oryginalnej procedury obsługi zasobów, ASP.NET bezpośrednio wywołuje procedurę obsługi wskazaną przez metodę Wykonaj i nie uruchamia ponownie logiki uwierzytelniania i autoryzacji dla nowego zasobu. Jeśli zasady bezpieczeństwa aplikacji wymagają od klientów posiadania odpowiedniej autoryzacji dostępu do zasobu, aplikacja powinna wymusić ponowną autoryzację lub zapewnić niestandardowy mechanizm kontroli dostępu.

Możesz wymusić ponowną autoryzację za pomocą metody Przekierowanie zamiast metody Wykonaj . Przekierowanie wykonuje przekierowanie po stronie klienta, w którym przeglądarka żąda nowego zasobu. Ponieważ to przekierowanie jest nowym żądaniem wchodzącym do systemu, podlega całej logice uwierzytelniania i autoryzacji zarówno Internetowych usług informacyjnych (IIS), jak i zasad bezpieczeństwa ASP.NET.

- z MSDN

Response.Redirect obejmuje dodatkową podróż w obie strony i aktualizuje pasek adresu.

Server.Transfer nie powoduje zmiany paska adresu, serwer odpowiada na żądanie treścią z innej strony

na przykład

Odpowiedź. Przekierowanie: -

1. Na kliencie przeglądarka żąda strony http: //InitiallyRequestedPage.aspx
2. Na serwerze odpowiada na żądanie 302 przekazując adres przekierowania http: //AnotherPage.aspx .
3. Na kliencie przeglądarka wysyła drugie żądanie na adres http: //AnotherPage.aspx .
4. Na serwerze odpowiada treścią z http: //AnotherPage.aspx

Server.Transfer: -

1. W przeglądarce klienta żąda strony http: //InitiallyRequestedPage.aspx
2. Na serwerze Server.Transfer do http: //AnotherPage.aspx
3. Na serwerze wysyłana jest odpowiedź na żądanie http: //InitiallyRequestedPage.aspx, które przekazuje treść z http: //AnotherPage.aspx

Odpowiedź. Przekierowanie

Plusy: - RESTful - Zmienia pasek adresu, adres może być używany do rejestrowania zmian stanu pomiędzy żądaniami.

Minusy: - powolne - istnieje dodatkowa podróż w obie strony między klientem a serwerem. Może to być kosztowne, gdy występuje znaczne opóźnienie między klientem a serwerem.

Server.Transfer

Plusy: - Szybko.

Minusy: - Stan utracony - Jeśli używasz Server.Transfer, aby zmienić stan aplikacji w odpowiedzi na zwrotne wiadomości, jeśli strona zostanie ponownie załadowana, stan zostanie utracony, ponieważ pasek adresu będzie taki sam, jak był na pierwsze żądanie.

Response.Redirect Response.Redirect () wyśle ​​cię na nową stronę, zaktualizuje pasek adresu i doda go do historii przeglądarki. W przeglądarce możesz kliknąć wstecz. Przekierowuje żądanie do niektórych zwykłych stron HTML na naszym serwerze lub na inny serwer WWW. Powoduje to dodatkowe objazdy do serwera na każde żądanie. Nie zachowuje ciągów zapytań i zmiennych formularzy z pierwotnego żądania. Pozwala zobaczyć nowy przekierowany adres URL, w którym jest przekierowany w przeglądarce (i być w stanie dodać go do zakładek, jeśli to konieczne). Odpowiedź. Przekierowanie po prostu wysyła wiadomość do przeglądarki (HTTP 302).

Server.Transfer Server.Transfer () nie zmienia paska adresu, nie możemy trafić wstecz. Należy użyć Server.Transfer (), gdy on / ona nie chce, aby użytkownik widział, dokąd zmierza. Kiedyś na stronie typu „ładowanie”. Przenosi bieżące żądanie strony na inną stronę .aspx na tym samym serwerze. Oszczędza zasoby serwera i pozwala uniknąć niepotrzebnych objazdów do serwera. Zachowuje ciąg zapytania i zmienne formularza (opcjonalnie). Nie pokazuje prawdziwego adresu URL, pod którym przekierowuje żądanie w przeglądarce internetowej użytkownika. Server.Transfer odbywa się bez wiedzy przeglądarki, przeglądarka żąda strony, ale serwer zwraca treść innej.