Hasta ahora con Transfer y Execute hemos visto que podemos ejecutar otras páginas del mismo tipo sin necesidad de redirección desde el lado cliente. Sin embargo un efecto secundario que tiene su uso es que, como no se regenera la petición sino que se ejecutan dentro del contexto de la petición actual, no entran en juego los controles de seguridad y otros eventos del pipeline HTTP para la segunda página. Es por ello por lo que en nuestro ejemplo se ha podido mostrar el contenido de la página "P2.aspx" a pesar de que estaba protegida. Existe una variante de estos métodos llamada TransferRequest que permite conseguir una petición completa desde el propio servidor, sin pasar por el cliente como ocurría con Redirect. Este método se utiliza del mismo modo que Transfer pero en este caso la segunda página pasa por todo los estadios de una petición HTTP normal, como si hubiera sido hecha desde el cliente desde... [Más]

En la entrega anterior de esta serie vimos a fondo cómo funcionaba el método Transfer. Seguimos ahora profundizando en otros métodos relacionados. El método Transfer por debajo lo único que hace es llamar al método Execute de la misma clase HttpUtility: Este método es prácticamente idéntico a Transfer, como vemos en este código, por lo que a todos los efectos podemos sustituir las llamadas a Transfer por llamadas a Execute y no perder funcionalidad. Además, si nos fijamos en el código de Transfer de una figura anterior, llama continuación a Response.End. Esto como ya vimos en la primera parte con Redirect, tiene algunas implicaciones respecto al rendimiento debido a la generación de excepciones ThreadAbortException, por lo que en sitios muy grandes donde cada milésima cuenta puede ser interesante sustituir las llamadas a Transfer por llamadas a Execute con una posterior a CompleteRequest (repasa el primer post para verlo). Si hacemos lo mismo que antes pero llamando a Execute en ... [Más]

En el post anterior de esta serie vimos cómo la forma más sencilla de transferir a un usuario desde una página a otra es mediante el uso de una redirección en el lado cliente, usando Redirect o RedirectPermanent. Sin embargo esto implica dos secuencias de petición-respuesta al servidor y además se visualiza la página final en la barra de direcciones del usuario. Muchas veces (la mayoría) es probable que sea lo que queremos, pero hay otras situaciones en las que no será así y lo que necesitaremos es que la ejecución se cambie en el servidor, de manera inadvertida para el usuario, por ejemplo: Ejecutar código común a varias páginas que hace uso de controles y genera elementos para la interfaz de usuario. En la mayor parte de los casos podríamos usar una biblioteca común o un control de usuario, pero si involucra páginas complejas o, simplemente, si ya tenemos la funcionalidad hecha en un ASPX y no queremos repetir el trabajo, nos vendrá bien poder transferir la ejecución a esta pág... [Más]

En ASP.NET existen muchos métodos para conseguir que cuando un usuario solicita una página en el servidor, acabe obteniendo el resultado de ejecutar otra página o recurso diferente. ¿Para qué querríamos hacer algo así? Por múltiples motivos, y en realidad es algo que se usa constantemente: Redirigir a los usuarios a una página nueva Ejecutar una funcionalidad que reside en otra página o recurso Ofrecer al usuario rutas amigables cuando por debajo usamos una estructura de páginas más compleja Hacer que las URLs antiguas de una aplicación sigan funcionando aunque hayamos cambiado la estructura del sitio .... El framework de ASP.NET ofrece muchos métodos diferentes de cambiar el recurso utilizado para responder a una petición, y cada uno tiene sus aplicaciones específicas. Así que ¿Cuál utilizar? Vamos a verlos todos para resolver las dudas y conocer bien sus diferencias y mejores aplicaciones. El ejemplo Para ilustrar en la práctica todos estos métodos he crea... [Más]