¿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?
Server.TransferRequest
lugar de hacerlo Server.Transfer
.
¿Cuál es la diferencia entre Server.Transfer
y Response.Redirect
?
Server.TransferRequest
lugar de hacerlo Server.Transfer
.
Respuestas:
Response.Redirect
simplemente envía un mensaje (HTTP 302) al navegador.
Server.Transfer
sucede sin que el navegador sepa nada, el navegador solicita una página, pero el servidor devuelve el contenido de otra.
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 de nuevo.
Server.Transfer()
no cambia la barra de direcciones. No puedes devolver el golpe.
Lo uso Server.Transfer()
cuando no quiero que el usuario vea a dónde voy. A veces en una página de tipo "cargando".
De lo contrario, siempre lo 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 una pequeña correcció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 comoServer.Transfer("WebForm2.aspx")
. Sin embargo, la declaración tiene varias ventajas y desventajas distintas.En primer lugar, la transferencia a otra página utilizando
Server.Transfer
conserva los recursos del servidor. En lugar de decirle al navegador que redirija, simplemente cambia el "foco" en el servidor web y transfiere la solicitud. Esto significa que no recibe tantas solicitudes HTTP, lo que alivia la presión sobre 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 aquellos sitios que se ejecutan en el servidor; no puede usar
Server.Transfer
para enviar al usuario a un sitio externo. SoloResponse.Redirect
puede hacer eso.En segundo lugar,
Server.Transfer
mantiene la URL original en el navegador. Esto realmente puede ayudar a racionalizar las técnicas de entrada de datos, aunque puede generar confusión al depurar.Eso no es todo: el
Server.Transfer
método también tiene un segundo parámetro: "preserveForm". Si establece esto enTrue
, utilizando una declaración comoServer.Transfer("WebForm2.aspx", True)
, la cadena de consulta existente y cualquier variable de formulario aún estarán 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 haciendo referencia
Request.Form("TextBox1")
.
maintaining the original URL... ...really help streamline data entry techniques
?
Response.Redirect()
debe usarse cuando:
Server.Transfer()
debe usarse cuando:
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 cierra 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 para elegir cuál es mejor.
Response.Redirect
para cargar la página original aunque haya llamado Response.Redirect
?
"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 / redireccionamiento es muy diferente.
En caso de que sea un tipo visual y le gustaría 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 que en "server.transfer" la realiza el servidor. Tratemos de entender esta declaración de manera más detallada.
En "Server.Transfer", a continuación se muestra la secuencia de cómo se realiza la transferencia: -
1.El usuario envía una solicitud a una página ASP.NET. En la figura siguiente, la solicitud se envía a "WebForm1" y nos gustaría navegar a "Webform2".
2. El servidor 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. Se crea el objeto de página "Webform2", se ejecuta el ciclo de vida completo de la página y luego se envía la respuesta HTML de salida al navegador.
Mientras que en "Response.Redirect", a continuación se muestra la secuencia de eventos para la navegación: -
1.El cliente (navegador) envía una solicitud a una página. En la figura siguiente, 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 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 a la página "Webform2.aspx".
4.Browser interpreta el comando 302 y envía una solicitud GET para "Webform2.aspx".
En otras palabras, el servidor ejecuta "Server.Transfer" mientras que el navegador thr ejecuta "Response.Redirect". "Response.Redirect" necesita dos solicitudes para hacer una redirección de la página.
Entonces, ¿cuándo usar "Server.Transfer" y cuándo usar "Response.Redirect"?
Use "Server.Transfer" cuando desee navegar por páginas que residen en el mismo servidor, use "Response.Redirect" cuando desee navegar entre páginas que residan en servidores y dominios diferentes.
A continuación se muestra una tabla resumen de las diferencias y en qué escenario utilizar.
Server.Transfer
: ¿ el mismo servidor o el mismo sitio web de IIS ?
La belleza de Server.Transfer es lo que puedes hacer con él:
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
Además del comentario de ScarletGarden, también debe tener en cuenta el impacto de los motores de búsqueda y su redirección. ¿Se ha movido esta página de forma permanente? ¿Temporalmente? Hace la 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. ¿Pero sabía que Response.Redirect envía un código de estado de respuesta HTTP de "302 encontrado" cuando realmente desea enviar "301 movido permanentemente"?
La distinción parece pequeña, pero en ciertos casos puede marcar una gran diferencia. Por ejemplo, si usa 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 con el nuevo. Si usa "302 encontrados", continuarán volviendo a la página anterior ...
La transferencia es completamente del lado del servidor. La barra de direcciones del cliente permanece constante. Alguna complejidad sobre la transferencia de contexto entre solicitudes. Vaciar y reiniciar los controladores de página puede ser costoso, por lo que debe realizar su transferencia al principio de la tubería, por ejemplo, en un HttpModule durante BeginRequest. Lea los documentos de MSDN cuidadosamente y pruebe y comprenda los nuevos valores de HttpContext.Request, especialmente en escenarios de devolución de datos. Usualmente usamos Server.Transfer para escenarios de error.
Redirect finaliza la solicitud con un estado 302 y una respuesta de ida y vuelta del lado del cliente con internamente y come una excepción (impacto menor en el rendimiento del servidor; depende de cuántas hagas por día) El cliente luego navega a una nueva dirección. Barra de direcciones del navegador y actualizaciones del historial, 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 redirigimos mucho , escribimos nuestro propio módulo para evitar el costo de excepción.
Hay muchas diferencias como se especificó anteriormente. Además de sobre 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.
//This will work.
Response.Redirect("http://www.google.com");
//This will not work.
Server.Transfer("http://www.google.com");
Response.Redirect es más costoso 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 confuso 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 usar este último enfoque.
Server.Transfer no cambia la URL en el navegador del cliente, por lo que efectivamente el navegador no sabe que ha cambiado 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 un poco más rápido, ya que evita un viaje de ida y vuelta al servidor, pero el no cambio de URL puede ser bueno o malo para usted, dependiendo de lo que intente 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 a la nueva página cargando su contenido en el navegador. Esto da como resultado dos solicitudes del navegador.
Server.Transfer: transfiere la ejecución desde la primera página a la segunda página en el 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 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 Execute (), lo que es ejecutar es el controlador de la ruta dada, vea
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 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 Execute y no vuelve a ejecutar la lógica de autenticación y 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 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 contenido de otra página
p.ej
Respuesta: Redireccionar: -
Server.Transfer: -
Respuesta Redireccionar
Pros: - RESTful - Cambia la barra de direcciones, la dirección se puede usar para registrar cambios de estado entre 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.
Server.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 era en la primera solicitud
Response.Redirect 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 de nuevo. Redirige la solicitud a algunas páginas HTML simples en nuestro servidor oa algún otro servidor web. Causa viajes de ida y vuelta adicionales al servidor en cada solicitud. No conserva las Cadenas de consulta y 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. Redirect 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 "cargando". Transfiere la solicitud de la 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 la cadena de consulta y las 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.