Pregunta

¿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 uno?
¿Fue útil?

Solución

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

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

Otros consejos

Response.Redirect () lo enviará a una nueva página, actualizará la barra de direcciones y la 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 " carga " tipo de página.

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

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 la URL igual y, con un poco de solución 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 que envía al usuario a otra página   con una declaración como Server.Transfer (" WebForm2.aspx ") . Sin embargo,   La declaración tiene varias ventajas y desventajas distintas.

     

En primer lugar, transferir a otra página usando Server.Transfer   conserva los recursos del servidor. En lugar de decirle al navegador que   redirigir, simplemente cambia el " foco " en el servidor web y   transfiere la solicitud. Esto significa que no obtienes tantos HTTP   solicitudes que llegan, lo que facilita la presión sobre su   Servidor web y hace que sus aplicaciones se ejecuten más rápido.

     

Pero ten cuidado: porque la " transferencia " El proceso puede funcionar solo en aquellos   sitios que se ejecutan en el servidor; no puede utilizar Server.Transfer para enviar   El 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 al depurar.

     

Eso no es todo: el método Server.Transfer también tiene un segundo   parámetro— " preserveForm " ;. Si configuras esto en True , usando una declaración   como Server.Transfer (" WebForm2.aspx " ;, True) , la consulta existente   La cadena y cualquier variable de formulario seguirán estando disponibles para la página que usted   se están transfiriendo a.

     

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

Response.Redirect () debe usarse cuando:

  • queremos redirigir la solicitud a algunas páginas HTML simples en nuestro servidor oa algún otro servidor web
  • no nos importa causar viajes de ida y vuelta adicionales al servidor en cada solicitud
  • no necesitamos preservar la cadena de consulta ni las variables de formulario de la solicitud original
  • queremos que nuestros usuarios puedan ver la nueva URL redirigida donde se redirige en su navegador (y poder marcarla si es necesario)

Server.Transfer () debe usarse cuando:

  • queremos transferir la solicitud de la 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 la cadena de consulta y las variables de formulario (opcionalmente)
  • no necesitamos mostrar la URL real a la que redirigimos la solicitud en el navegador web de los usuarios

Response.Redirect redirige la página a otra página después de que la primera página llegue al cliente. Así que 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 tus necesidades elegir cuál es mejor.

ingrese la descripción de la imagen aquí

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

En caso de que usted sea un hombre visual y quisiera ver una demostración en lugar de una teoría, sugeriría ver 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 está en " server.transfer " Lo hace el servidor. Intentemos comprender esta declaración de manera más detallada.

En " Server.Transfer " La siguiente es la secuencia de cómo ocurre la transferencia: -

1.El usuario envía una solicitud a una página ASP.NET. En la siguiente figura, la solicitud se envía a " WebForm1 " y nos gustaría navegar a " Webform2 " ;.

2.Server comienza a ejecutar " Webform1 " Y comienza 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. " Webform2 " se crea un objeto de página, se ejecuta el ciclo de vida completo de la página y luego se envía la respuesta HTML de salida al navegador.

ingrese la descripción de la imagen aquí

Mientras está en " Respuesta.Redirigir " La siguiente es la secuencia de eventos para la navegación: -

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

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

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

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

ingrese la descripción de la imagen aquí

En otras palabras, " Server.Transfer " es ejecutado por el servidor mientras " Response.Redirect " Es ejecutado por el navegador de thr. " Respuesta. Redirigir " 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 páginas que residen en el mismo servidor, use " Response.Redirect " cuando desee navegar entre páginas que residen en un servidor y dominio diferentes.

ingrese la descripción de la imagen aquí

A continuación se muestra una tabla de resumen en la que se destacan las diferencias y en qué escenario se debe utilizar.

ingrese la descripción de la imagen aquí

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

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

Puedes obtener cualquier cosa de tu página anterior usando el método anterior siempre y cuando uses Server.Transfer pero no Response.Redirect

Además del comentario de ScarletGarden, también debe considerar el impacto de los motores de búsqueda y su redirección. ¿Esta página se ha movido permanentemente? ¿Temporalmente? Hace una diferencia.

vea: Response.Redirect vs. " 301 Movido permanentemente " :

  

Todos hemos utilizado Response.Redirect en   una vez u otra Es el rapido   Y una manera fácil de atraer visitantes.   en la dirección correcta si de alguna manera   Terminar en el lugar equivocado. Pero tu   saber que Response.Redirect envía un   Código de estado de respuesta HTTP de " 302   Encontrado " cuando realmente quieras   enviar " 301 Movido permanentemente " ;?

     

La distinción parece pequeña, pero en   ciertos casos en realidad puede hacer una   gran diferencia. Por ejemplo, si usted   utilizar un " 301 Movido permanentemente " respuesta   Código, la mayoría de los motores de búsqueda eliminarán   el enlace obsoleto de su índice y   Reemplázalo con el nuevo. Si tu   use " 302 Found " ;, continuarán   volviendo a la antigua página ...

La transferencia es completamente del lado del servidor. La barra de direcciones del cliente permanece constante. Alguna complejidad sobre la transferencia de contexto entre peticiones. La descarga y el reinicio de los manejadores de páginas pueden ser costosos, por lo que su transferencia al principio del proceso, por ejemplo en un HttpModule durante BeginRequest. Lea atentamente los documentos de MSDN y pruebe y comprenda los nuevos valores de HttpContext.Request, especialmente en los escenarios de devolución de datos. Usualmente usamos Server.Transfer para situaciones de error.

El redireccionamiento finaliza la solicitud con un estado 302 y una respuesta de ida y vuelta del lado del cliente con y come internamente una excepción (menor impacto del servidor: depende de la cantidad que haga al día) El cliente luego navega a una nueva dirección. Barra de direcciones del navegador & amp; actualizaciones de la historia, etc. El cliente paga el costo de un viaje de 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.

Respuesta. La redirección es más costosa ya que agrega un viaje adicional al servidor para averiguar a dónde ir.

Server.Transfer es más eficiente, sin embargo, puede ser un poco engañoso 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 este último enfoque

Hay muchas diferencias como se especificó anteriormente. Aparte 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 aplicación.

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

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

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 la url en la barra de título cambia.

Server.Transfer es ligeramente más rápido, ya que evita un viaje de ida y vuelta al servidor, pero la no modificación de la URL puede ser buena o mala para ti, dependiendo de lo que estés intentando hacer.

Response.Redirect: le dice al navegador que la página solicitada se puede encontrar en una nueva ubicación. Luego, el navegador inicia otra solicitud para que la nueva página cargue su contenido en el navegador. Esto da lugar a dos solicitudes por el 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 es la que responde con contenido. El beneficio de este enfoque es un viaje de ida y vuelta 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.

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 Ejecutar (), lo que se debe ejecutar es el controlador de la ruta de acceso dada, consulte

  

ASP.NET no verifica que el usuario actual esté autorizado para ver el recurso entregado por el método Ejecutar . Aunque la lógica de autenticación y autorización de ASP.NET se ejecuta antes de que se llame al controlador de recursos original, ASP.NET llama directamente al controlador indicado por el método Ejecutar 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 una redirección del lado del cliente en la que el navegador solicita el nuevo recurso. Debido a que 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 los Servicios de información de Internet (IIS) y la política de seguridad de ASP.NET.

     

- de MSDN

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

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

por ejemplo

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 redireccionamiento 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

Servidor.Transferencia:-

  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 devolviendo el contenido desde http: //AnotherPage.aspx

Response.Redirect

Pros: - RESTful: cambia la barra de direcciones, la dirección se puede usar para registrar los 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.Transferencia

Pros: - Rápido.

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

Response.Redirect Response.Redirect () te enviará a una nueva página, actualizará la barra de direcciones y la 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 algún otro servidor web. Provoca viajes de ida y vuelta adicionales al servidor en cada solicitud. No conserva la cadena de consulta ni las variables de formulario de la solicitud original. Permite ver la nueva URL redirigida donde se redirige en el navegador (y poder marcarla si es necesario). Respuesta. La redirección simplemente envía un mensaje al navegador (HTTP 302).

Server.Transfer Server.Transfer () no cambia la barra de direcciones, no podemos devolverle el golpe. Uno debe usar Server.Transfer () cuando no quiere que el usuario vea a dónde se dirige. En algún momento en un " carga " tipo de página 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 cadenas de consulta y variables de formulario (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 otra.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top