asp.net - Server.Transfer vs. Response.Redirect

Question

¿Cuál es la diferencia entre Server.Transfer y Response.Redirect ?

• ¿Cuáles son las ventajas y desventajas de cada uno?
• ¿Cuándo es apropiado uno sobre el otro?
• ¿Cuándo no es apropiado?

Answer 1

Response.Redirect implica un viaje adicional de ida y vuelta y actualiza la barra de direcciones.

Server.Transfer no hace que la barra de direcciones cambie, el servidor responde a la solicitud con contenido de otra página

p.ej

Response.Redirect: -

1. En el cliente, el navegador solicita una página http: //InitiallyRequestedPage.aspx
2. En el servidor responde a la solicitud con 302 pasando la dirección de redirección http: //AnotherPage.aspx .
3. En el cliente, el navegador realiza una segunda solicitud a la dirección http: //AnotherPage.aspx .
4. En el servidor responde con contenido de http: //AnotherPage.aspx

Server.Transfer: -

1. En el navegador del cliente solicita una página http: //InitiallyRequestedPage.aspx
2. En el servidor Server.Transfer a http: //AnotherPage.aspx
3. En el servidor, se responde a la solicitud de http: //InitiallyRequestedPage.aspx que reenvía contenido desde http: //AnotherPage.aspx

Response.Redirect

Pros: - RESTful. Cambia la barra de direcciones, la dirección se puede usar para registrar cambios de estado entre las solicitudes.

Contras: - Lento - Hay un viaje de ida y vuelta adicional entre el cliente y el servidor. Esto puede ser costoso cuando hay una latencia sustancial entre el cliente y el servidor.

Servidor.Transfer

Pros: - Rápido.

Contras: - Estado perdido - Si está utilizando Server.Transfer para cambiar el estado de la aplicación en respuesta a las publicaciones posteriores, si la página se vuelve a cargar ese estado se perderá, ya que la barra de direcciones será la misma que en la primera solicitud

Answer 2

La transferencia es completamente del lado del servidor. La barra de dirección del cliente permanece constante. Alguna complejidad sobre la transferencia de contexto entre las solicitudes. Limpiar y reiniciar los manejadores de página puede ser costoso, así que haga su transferencia al principio de la canalización, por ejemplo, en un HttpModule durante BeginRequest. Lea los documentos de MSDN con cuidado, y pruebe y comprenda los nuevos valores de HttpContext.Request, especialmente en los escenarios de Postback. Usualmente usamos Server.Transfer para escenarios de error.

Redirigir finaliza la solicitud con un estado 302 y una respuesta de ida y vuelta del lado del cliente e internamente se come una excepción (golpe menor de rendimiento del servidor - depende de la cantidad que haga al día) El cliente luego navega a una nueva dirección. La barra de direcciones del navegador y las actualizaciones de historial, etc. El cliente paga el costo de una ida y vuelta adicional; el costo varía según la latencia. En nuestro negocio redireccionamos mucho , escribimos nuestro propio módulo para evitar el costo de la excepción.

Answer 3

Response.Redirect es más costoso ya que agrega un viaje adicional al servidor para descubrir a dónde ir.

Server.Transfer es más eficiente, sin embargo puede ser un poco erróneo para el usuario ya que la URL no cambia físicamente.

En mi experiencia, la diferencia en el rendimiento no ha sido lo suficientemente significativa como para utilizar el último enfoque

Answer 4

Además del comentario de ScarletGarden, también debes considerar el impacto de los motores de búsqueda y tu redirección. ¿Esta página se movió de forma permanente? ¿Temporalmente? Hace una diferencia.

ver: Response.Redirect vs. "301 movido permanentemente" :

Todos hemos usado Response.Redirect en un momento u otro. Es la manera rápida y fácil de hacer que los visitantes apunten en la dirección correcta si de alguna manera terminan en el lugar equivocado. ¿Sabía que Response.Redirect envía un código de estado de respuesta HTTP de "302 Found" cuando es posible que desee enviar "301 Moved Permanently"?

La distinción parece pequeña, pero en ciertos casos puede marcar una gran diferencia. Por ejemplo, si utiliza un código de respuesta "301 Movido permanentemente", la mayoría de los motores de búsqueda eliminarán el enlace desactualizado de su índice y lo reemplazarán por uno nuevo. Si usa "302 Found", continuarán volviendo a la página anterior ...

Answer 5

Response.Redirect redirige la página a otra página después de que llega la primera página al cliente. Entonces el cliente conoce la redirección.

Server.Transfer abandona la ejecución actual de la página. El cliente no conoce la redirección. Le permite transferir la cadena de consulta y las variables de formulario.

Por lo tanto, depende de sus necesidades elegir cuál es mejor.

Answer 6

Server.Transfer no cambia la URL en el navegador del cliente, por lo que efectivamente el navegador no sabe que se cambió a otro controlador del lado del servidor. Response.Redirect le dice al navegador que se mueva a una página diferente, por lo que cambia la url en la barra de título.

Server.Transfer es ligeramente más rápido ya que evita una ida y vuelta al servidor, pero el no cambio de la URL puede ser bueno o malo para usted, dependiendo de lo que esté tratando de hacer.

Answer 7

Response.Redirect: le dice al navegador que la página solicitada se puede encontrar en una nueva ubicación. El navegador luego inicia otra solicitud a la nueva página cargando sus contenidos en el navegador. Esto da como resultado dos solicitudes del navegador.

Server.Transfer: transfiere la ejecución de la primera página a la segunda página del servidor. En lo que respecta al cliente del navegador, realizó una solicitud y la página inicial responde con el contenido. El beneficio de este enfoque es un viaje redondo menos al servidor desde el navegador del cliente. Además, cualquier variable de formulario publicada y parámetros de cadena de consulta también están disponibles para la segunda página.

Answer 8

La belleza de Server.Transfer es lo que puedes hacer con ella:

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

Puede obtener cualquier cosa de su página anterior utilizando el método anterior siempre que use Server.Transfer pero no Response.Redirect

Answer 9

Para ser breve: Response.Redirect simplemente le dice al navegador que visite otra página. Server.Transfer ayuda a reducir las solicitudes del servidor, mantiene el mismo URL y, con un pequeño ataque de errores, le permite transferir la cadena de consulta y las variables de formulario.

Algo que encontré y estoy de acuerdo con ( fuente ):

Server.Transfer es similar en el sentido de que envía al usuario a otra página con una declaración como Server.Transfer("WebForm2.aspx") . Sin embargo, la declaración tiene una serie de claras ventajas y desventajas.

En primer lugar, transferir a otra página utilizando Server.Transfer conserva los recursos del servidor. En lugar de indicarle al navegador que redirija, simplemente cambia el "foco" en el servidor web y transfiere la solicitud. Esto significa que no obtiene la misma cantidad de solicitudes HTTP, lo que alivia la presión en su servidor web y hace que sus aplicaciones se ejecuten más rápido.

Pero cuidado: porque el proceso de "transferencia" puede funcionar solo en los sitios que se ejecutan en el servidor; no puede usar Server.Transfer para enviar al usuario a un sitio externo. Solo Response.Redirect puede hacer eso.

En segundo lugar, Server.Transfer mantiene la URL original en el navegador. Esto realmente puede ayudar a simplificar las técnicas de entrada de datos, aunque puede crear confusión cuando se depura.

Eso no es todo: el método Server.Transfer también tiene un segundo parámetro: "preserveForm". Si establece esto en True , utilizando una instrucción como Server.Transfer("WebForm2.aspx", True) , la cadena de consulta existente y las variables de formulario seguirán estando disponibles para la página a la que está transfiriendo.

Por ejemplo, si su WebForm1.aspx tiene un control TextBox llamado TextBox1 y lo transfirió a WebForm2.aspx con el parámetro preserveForm establecido en True, podrá recuperar el valor del control TextBox de la página original al hacer referencia a Request.Form("TextBox1") .

Answer 10

Hay muchas diferencias como se especifica arriba. Además de todo, hay una diferencia más. Response.redirect () se puede usar para redirigir al usuario a cualquier página que no sea parte de la aplicación, pero server.transfer () solo se puede usar para redirigir al usuario dentro de la aplicación.

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

Answer 11

Solo más detalles sobre Transfer (), en realidad es Server.Execute () + Response.End (), su código fuente está debajo (de Mono / .net 4.0):

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

y para Execute (), lo que es ejecutar es el manejador de la ruta dada, ver

ASP.NET no verifica que el usuario actual esté autorizado para ver el recurso entregado por el método Execute . Aunque la lógica de autorización y autenticación de ASP.NET se ejecuta antes de llamar al controlador de recursos original, ASP.NET llama directamente al controlador indicado por el método Execute y no vuelve a ejecutar la autenticación y la lógica de autorización para el nuevo recurso. Si la política de seguridad de su aplicación requiere que los clientes tengan la autorización adecuada para acceder al recurso, la aplicación debe forzar la reautorización o proporcionar un mecanismo de control de acceso personalizado.

Puede forzar la reautorización utilizando el método Redirect en lugar del método Execute . Redirect realiza un redireccionamiento del lado del cliente en el que el navegador solicita el nuevo recurso. Como esta redirección es una nueva solicitud que ingresa al sistema, está sujeta a toda la lógica de autenticación y autorización de Internet Information Services (IIS) y la política de seguridad de ASP.NET.

- de MSDN

Answer 12

"response.redirect" y "server.transfer" ayudan a transferir usuarios de una página a otra mientras la página se está ejecutando. Pero la forma en que hacen esta transferencia / redirección es muy diferente.

En caso de que seas un tipo visual y te gustaría ver una demostración en lugar de una teoría, te sugiero que veas el siguiente video de facebook que explica la diferencia de una manera más demostrativa.

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

La principal diferencia entre ellos es quién hace la transferencia. En "response.redirect", la transferencia la realiza el navegador, mientras que en "server.transfer" la realiza el servidor. Permítanos tratar de entender esta declaración de una manera más detallada.

En "Server.Transfer" a continuación está la secuencia de cómo ocurre la transferencia: -

1.User envía una solicitud a una página ASP.NET. En la figura a continuación, la solicitud se envía a "WebForm1" y nos gustaría navegar a "Webform2".

2. El servidor comienza a ejecutar "Webform1" y se inicia el ciclo de vida de la página. Pero antes de que se complete el ciclo de vida completo de la página, "Server.transfer" pasa a "WebForm2".

3. Se crea el objeto de página "Webform2", se ejecuta el ciclo de vida de la página completa y la respuesta HTML de salida se envía al navegador.

Mientras que en "Response.Redirect" siguiente es la secuencia de eventos para la navegación: -

1.Client (navegador) envía una solicitud a una página. En la figura a continuación, la solicitud se envía a "WebForm1" y nos gustaría navegar a "Webform2".

2.El ciclo de vida de "Webform1" comienza a ejecutarse. Pero en el medio del ciclo de vida ocurre "Response.Redirect".

3. Ahora, en lugar de que el servidor haga una redirección, envía un comando HTTP 302 al navegador. Este comando le dice al navegador que tiene que iniciar una solicitud GET en la página "Webform2.aspx".

4.Browser interpreta el comando 302 y envía una solicitud GET para "Webform2.aspx".

En otras palabras, "Server.Transfer" es ejecutado por el servidor mientras que "Response.Redirect" es ejecutado por el navegador thr. "Response.Redirect" necesita dos solicitudes para hacer un redireccionamiento de la página.

Entonces, ¿cuándo usar "Server.Transfer" y cuándo usar "Response.Redirect"?

Utilice "Server.Transfer" cuando desee navegar por las páginas que residen en el mismo servidor, use "Response.Redirect" cuando desee navegar entre las páginas que residen en diferentes servidores y dominios.

A continuación se encuentra una tabla resumen de las diferencias y el escenario a usar.

Answer 13

Response.Redirect() lo enviará a una nueva página, actualizará la barra de direcciones y lo agregará al Historial del navegador. En su navegador puede hacer clic atrás.

Server.Transfer() no cambia la barra de direcciones. No puedes devolver el golpe.

Uso Server.Transfer() cuando no quiero que el usuario vea a dónde voy. A veces en una página de tipo "carga".

De lo contrario, siempre usaré Response.Redirect() .

Answer 14

Response.Redirect simplemente envía un mensaje (HTTP 302) al navegador.

Server.Transfer ocurre sin que el navegador sepa nada, el navegador solicita una página, pero el servidor devuelve el contenido de otro.

Answer 15

Response.Redirect Response.Redirect () lo enviará a una nueva página, actualizará la barra de direcciones y lo agregará al historial del navegador. En su navegador puede hacer clic atrás. Redirige la solicitud a algunas páginas HTML simples en nuestro servidor o a otro servidor web. Causa viajes de ida y vuelta adicionales al servidor en cada solicitud. No conserva la Cadena de consulta y las Variables de formulario de la solicitud original. Permite ver la nueva URL redirigida a la que se redirige en el navegador (y poder marcarla si es necesario). Respuesta. Redirigir simplemente envía un mensaje al navegador (HTTP 302).

Server.Transfer Server.Transfer () no cambia la barra de direcciones, no podemos devolver el golpe. Uno debe usar Server.Transfer () cuando no quiere que el usuario vea a dónde va. En algún momento en una página de tipo "carga". Transfiere la solicitud de página actual a otra página .aspx en el mismo servidor. Conserva los recursos del servidor y evita los viajes de ida y vuelta innecesarios al servidor. Conserva cadena de consulta y variables de forma (opcionalmente). No muestra la URL real donde redirige la solicitud en el navegador web de los usuarios. Server.Transfer ocurre sin que el navegador sepa nada, el navegador solicita una página, pero el servidor devuelve el contenido de otro.

Answer 16

Response.Redirect() debe usar cuando:

• queremos redirigir la solicitud a algunas páginas HTML simples en nuestro servidor o a otro servidor web
• no nos importa causar viajes de ida y vuelta adicionales al servidor en cada solicitud
• no es necesario que preservemos la Cadena de consulta y las Variables de formulario de la solicitud original
• queremos que nuestros usuarios puedan ver la nueva URL redirigida a la que se redirige en su navegador (y poder marcarla si es necesario)

Server.Transfer() debe usar cuando:

• queremos transferir la solicitud de página actual a otra página .aspx en el mismo servidor
• queremos preservar los recursos del servidor y evitar los viajes de ida y vuelta innecesarios al servidor
• queremos conservar Cadena de consulta y variables de forma (opcionalmente)
• no necesitamos mostrar la URL real donde redirigimos la solicitud en el navegador web de los usuarios

Answer 17

1. Al igual que el hipervínculo y Response.Redirect, Server.Transfer se usa para navegar a otras páginas / sitios que se ejecutan en el mismo servidor web.
2. Server.Transfer no se puede usar para navegar a sitios / páginas en un servidor web diferente.
3. Server.Transfer no cambia la URL en la barra de direcciones
4. Server.Transfer es más rápido que Response.Redirect ya que la redirección ocurre en el servidor en un ciclo de solicitud / respuesta. Response.Redirect () implica 2 ciclos de solicitud / respuesta.
5. Con Server.Transfer, se conservan las variables de formulario de la solicitud original.

Answer 18

Server.Transfer (): el cliente se muestra tal como está en la página de solicitud solamente, pero todo el contenido es de la página solicitada. Los datos pueden persistir en todas las páginas utilizando la colección Context.Item, que es una de las mejores maneras de transferir datos de una página a otra manteniendo vivo el estado de la página.

Response.Redirect (): el cliente conoce la ubicación física (nombre de la página y cadena de consulta también). Context.Items pierde la persistencia cuando navega a la página de destino. En versiones anteriores de IIS, si queríamos enviar un usuario a una nueva página web, la única opción que teníamos era Response.Redirect. Si bien este método cumple nuestra meta, tiene varios inconvenientes importantes. El mayor problema es que este método hace que cada página se trate como una transacción separada. Además de dificultar el mantenimiento de su integridad transaccional, Response.Redirect introduce algunos dolores de cabeza adicionales. Primero, evita una buena encapsulación del código. Segundo, pierde acceso a todas las propiedades en el objeto Request. Claro, hay soluciones, pero son difíciles. Finalmente, Response.Redirect necesita un viaje redondo al cliente, que, en sitios de gran volumen, causa problemas de escalabilidad.