¿Cuál es la diferencia entre Server.Transfer y Response.Redirect?Server.Transfer vs. Response.Redirect
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 otra.
¿Funciona esto con páginas CSHTML con matriz web? Parece que no puedo hacer que funcione cuando hago un Server.Transfer a una página de CSHTML como Server.Transfer ("~/somepage.cshtml", true) pero parece funcionar para otros tipos de páginas. Sí, tengo la afeitadora instalada y las páginas funcionan de la manera esperada. –
Hola, descubrí. Debe usar Server.TransferRequest para páginas de matriz web cshtml. –
¿Server.Transfer() solo se transfiere a páginas físicas? por ej. si me transfiero a Server.Transfer ("default/category1.aspx") ¿es necesario tener una carpeta predeterminada y una categoría 1, página aspx en ella? – ihimv
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 erróneo para el usuario ya que la URL no cambia físicamente.
En mi experiencia, la diferencia de rendimiento no ha sido lo suficientemente importantes como para usar este último enfoque
transferencia es enteramente del lado del servidor. La barra de dirección del cliente permanece constante. Alguna complejidad sobre la transferencia de contexto entre las solicitudes. La descarga y el reinicio de los manejadores de la página pueden ser costosos, por lo que su transferencia debe realizarse antes en la tubería, p. 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. Barra de direcciones del navegador & actualizaciones de historia, etc. El cliente paga el costo de una 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 la excepción.
Response.Redirect() le 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 página de tipo "carga".
De lo contrario, siempre usaré Response.Redirect().
Response.Redirect redirige la página a otra página después de 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.
¿Puede un usuario malintencionado omitir 'Response.Redirect' para cargar la página original aunque he llamado' Response.Redirect'? – northben
@northben - Nunca es fácil decir "no" cuando se trata de tecnología, ya que casi cualquier cosa puede verse comprometida, pero en este caso, ¿cómo podrían hacerlo? Yo diría que no, no podrían ... pero me han demostrado que no es cierto. tiempos en la vida. – JonH
Servidor.La transferencia no cambia la URL en el navegador del cliente, por lo que efectivamente el navegador no sabe que usted 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.
Además del comentario de ScarletGarden, también debe tener en cuenta el impacto de los motores de búsqueda y su redirección. ¿Esta página se movió de forma permanente? ¿Temporalmente? Hace una diferencia.
ver: Response.Redirect vs. "301 Moved Permanently":
Todos hemos utilizado Response.Redirect en un momento u otro. Es el rápido y la manera 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 podría querer enviar "301 Movido permanentemente"?
La distinción parece pequeña, pero en casos en realidad puede hacer 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 obsoleto de su índice y lo sustituirán por el nuevo. Si se utiliza "302 Found", que continuarán volviendo a la página de edad ...
Para ser breve: Response.Redirect simplemente le dice al navegador para visitar 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 (source):
Server.Transferes similar, ya 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.Transferconserva los recursos del servidor. En lugar de indicar al navegador redirigir, 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.Transferpara enviar el usuario a un sitio externo. SoloResponse.Redirectpuede hacer eso.En segundo lugar,
Server.Transfermantiene la URL original en el navegador. Esto realmente puede ayudar a agilizar las técnicas de entrada de datos, aunque puede crear confusión cuando se depura.Eso no es todo: el método
Server.Transfertambién tiene un segundo parámetro - "preserveForm". Si establece esto enTrue, utilizando una instrucción comoServer.Transfer("WebForm2.aspx", True), la cadena de consulta existente y cualquier variable de formulario seguirán estando disponibles para la página a la que se está transfiriendo .Por ejemplo, si su WebForm1.aspx tiene un control de cuadro de texto denominado TextBox1 y se transfiere a WebForm2.aspx con el parámetro preserveForm se establece en True, usted será capaz de recuperar el valor del cuadro de texto página original control haciendo referencia a
Request.Form("TextBox1").
+1 para comentarios, pero esto parece copiado textualmente de http://www.developer.com/net/asp/article.php/3299641. Si es de otra fuente, deberías alquilarla citarla. –
... pero lo han copiado, deberían citarlo. –
Dije: algo que encontré y con el que estoy de acuerdo; – TStamper
Response.Redirect() debe utilizarse cuando:
Server.Transfer() debe utilizarse cuando:
Response.Redirect: indica 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 en el 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.
La belleza de Server.Transfer es lo que puede hacer con él:
TextBox myTxt = (TextBox)this.Page.PreviousPage.FindControl("TextBoxID");
Usted puede conseguir cualquier cosa de su página anterior utilizando el método anterior, siempre y cuando se utiliza Server.Transfer pero no respuesta.Redirigir
Existen muchas diferencias según lo especificado 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.
sólo más detalles acerca de Transferencia(), en realidad es Server.Execute() + Response.End(), su código fuente está por 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 va a ejecutar es el manejador de de la ruta dada, ver
ASP.NET no verifica que el usuario actual está autorizado para ver el recurso entregado por el Ejecute el método. 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 reautorización utilizando el métodoredirección en lugar de la Ejecutar método. Redirigir realiza una redirección del lado del cliente en la 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.
Response.Redirect implica un ida y vuelta extra y actualiza la barra de direcciones.
Server.Transfer no causa la barra de direcciones para cambiar, el servidor responde a la solicitud con el contenido de otra página
por ejemplo,
Response.Redirect: -
servidor.Transferencia: -
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.
Server.Transfer
Pros: - rápidos.
Contras: - Estado perdieron - Si utiliza Server.Transfer para cambiar el estado de la aplicación en respuesta a publicar la espalda, si la página se vuelve a cargar entonces ese estado se perderá, como la barra de direcciones será el mismo que en la primera solicitud.
"response.redirect" y "Server.Transfer" ayuda a transferir el usuario de una página a otra página, mientras que la página está ejecutando. Pero la forma en que hacen esta transferencia/redirección es muy diferente.
En caso de que usted sea visual y quisiera ver una demostración en lugar de una teoría, le sugiero que vea el 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 el que 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" siguiente es la secuencia de cómo se produce 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 se envía la respuesta HTML de salida 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 THR navegador. "Response.Redirect" necesita dos solicitudes para hacer un redireccionamiento de la página.
¿Cuándo usar "Server.Transfer" y cuándo usar "Response.Redirect"?
Use "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 muestra una tabla resumen de los cuales tizas diferencias y en el que escenario de usar.
Response.Redirect Response.Redirect() le enviará a una nueva página, actualice la barra de direcciones y añadirlo a la historia 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 cadena de consulta y 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 golpear back.One debe utilizar Server.Transfer() cuando él/ella no quiere que el usuario vea dónde está yendo. 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 formulario (opcionalmente). No muestra la URL real donde redirige la solicitud en el navegador web de los usuarios. Server.Transfer sucede sin que el navegador sepa nada, el navegador solicita una página, pero el servidor devuelve el contenido de otro.
Server.Transfer(): cliente se muestra como lo es sólo en la página solicitante, pero el 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(): 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.
Server.Transfer reduce las solicitudes de página, por lo que supongo que es "mejor" en ese sentido. Sin embargo, Response.Redirect puede enviar al usuario a un sitio externo mientras Server.Transfer no puede. – codeConcussion
Si está ejecutando el modo integrado de IIS 7, puede considerar el uso de ['Server.TransferRequest'] (http://msdn.microsoft.com/en-us/library/system.web.httpserverutility.transferrequest.aspx) en lugar de 'Server.Transfer'. – Haacked
Las ventajas y desventajas se han indicado en el siguiente sitio. http://www.developer.com/net/asp/article.php/3299641 Un punto interesante en el artículo es que Server.Transfer consume más potencia de servidor en comparación con Server.Redirect. –