Reescritura de URL (1): IIS o ASP.NET

Para comprender completamente los temas que se analizan más adelante en el artículo, debemos comprender brevemente el proceso de comunicación entre IIS y ASP.NET. Lo que estoy explicando aquí es el servidor IIS 6. En cuanto a IIS 5 e IIS 7, se puede decir que el primero ha sido eliminado, mientras que el "modo clásico" del segundo es exactamente el mismo que IIS 6, y el nuevo "modo canalización" en realidad habla de algunos conceptos en ASP. NET e IIS. Integración profunda. Creo que si comprende IIS 6 y ASP.NET, no tendrá ningún problema en el modo integrado de IIS 7.

Primero, echemos un vistazo a un diagrama esquemático simple, que muestra varios pasos principales en todo el proceso de IIS desde la recepción de la Solicitud hasta la devolución de la Respuesta:

1. IIS recibe la solicitud.
2. El selector selecciona una ISAPI para manejar la solicitud según las características de la URL y la configuración en IIS; ahora es natural elegir ASP.NET ISAPI.
3. El motor de ejecución ASP.NET recibe la solicitud e inicializa los datos (como crear varios objetos).
4. Comience a activar varios eventos de Pipeline, comenzando naturalmente con BeginRequest.
5. Después de múltiples eventos de Pipeline, ASP.NET selecciona un Handler o HandlerFactory adecuado para la solicitud actual de acuerdo con la configuración (excepto en circunstancias especiales, como generar directamente los resultados y finalizar la solicitud en el evento anterior).
6. Después de ser procesado por el Handler, pasa por varios eventos de Pipeline y finaliza con EndRequest.
7. Respuesta de salida.

Si desea realizar una reescritura de URL en una aplicación ASP.NET, normalmente llama al método RewritePath de HttpContext en el evento BeginRequest para reposicionar la solicitud en una URL de destino. Por ejemplo, podemos anular el método Application_BeginRequest en Global.asax para lograr esto:

la razón por la que se realiza la reescritura en BeginRequest es porque este evento es el primero que se activa entre todos los eventos de Pipeline. Después del reposicionamiento en este momento, algunas propiedades en el HttpContext actual también cambiaron en consecuencia (como HttpContext.Request.Path). De esta forma, la lógica del controlador de los siguientes eventos de Pipeline se verá afectada. Por ejemplo, cuando es necesario determinar los permisos en función de un directorio, se utilizará la ruta "ubicada" en lugar de la solicitud recibida por ASP.NET. Naturalmente, el cambio más "significativo" es la elección del controlador. Por ejemplo, en el ejemplo anterior, reubicamos la solicitud en el archivo "CustomerList.aspx", para que el motor ASP.NET seleccione System.Web.UI. correspondiente a *.aspx. La clase PageHandlerFactory maneja las solicitudes.

clase pública Global : System.Web .
{
    void protegido Application_BeginRequest (remitente del objeto , EventArgs e)
    {
        Contexto HttpContext = HttpContext .Actual;
 
        if (context.Request.Path.Equals( "/Clientes" ,
            StringComparison .InvariantCultureIgnoreCase))
        {
            contexto.RewritePath( "~/CustomerList.aspx" );
        }
    }
}

Como último comentario, hay dos conceptos que deben distinguirse, a saber, "ASP.NET Pipeline" y "Web Forms". Ambos son modelos importantes en ASP.NET, pero las diferencias siguen siendo muy grandes:

• ASP.NET Pipeline: Como cada solicitud recibida por una aplicación ASP.NET, será procesada a través de este "pipeline". Este es un modelo de nivel ASP.NET.
• Formularios web: durante la ejecución de ASP.NET Pipeline, uno de los pasos es seleccionar un controlador adecuado (o HandlerFactory) para manejar la solicitud. Si es una página aspx, ASP.NET elegirá la clase System.Web.UI.PageHandlerFactory, en la que finalmente se forma el modelo WebForms.

De hecho, la palabra "forma" en la oración anterior puede no ser exacta. Porque Web Forms probablemente debería ser un motor y modelo de ejecución que se pueda usar de forma independiente, y System.Web.UI.PageHandlerFactory solo usa este modelo. Cuando escribimos aplicaciones ASP.NET, podemos usar este modelo en otros lugares según nuestras necesidades. Por ejemplo, en el artículo " Técnica: uso del control de usuario para la generación de HTML ", utilizamos ascx como plantilla en un controlador genérico para generar contenido.