Réécriture d'URL（1）：IIS et ASP.NET

Pour bien comprendre les sujets abordés plus loin dans l'article, nous devons comprendre brièvement le processus de communication entre IIS et ASP.NET. Ce que j'explique ici, c'est le serveur IIS 6. Quant à IIS 5 et IIS 7, on peut dire que le premier a été éliminé, tandis que le « mode classique » du second est exactement le même que IIS 6, et le nouveau « mode pipeline » parle en fait de certains concepts d'ASP. NET et IIS. Je pense que si vous comprenez IIS 6 et ASP.NET, vous n'aurez aucun problème en mode intégré d'IIS 7.

Tout d'abord, examinons un diagramme schématique simple, montrant plusieurs étapes principales de l'ensemble du processus d'IIS, depuis la réception de la requête jusqu'au retour de la réponse :

1. IIS reçoit la demande.
2. Le sélecteur sélectionne un ISAPI pour gérer la requête en fonction des caractéristiques de l'URL et de la configuration dans IIS. Il est désormais naturel de choisir ASP.NET ISAPI.
3. Le moteur d'exécution ASP.NET reçoit la requête et initialise les données (par exemple en créant divers objets).
4. Commencez à déclencher divers événements Pipeline, en commençant naturellement par BeginRequest.
5. Après plusieurs événements Pipeline, ASP.NET sélectionne un Handler ou HandlerFactory approprié pour la requête actuelle en fonction de la configuration (sauf circonstances particulières, telles que la sortie directe des résultats et la fin de la requête dans l'événement précédent).
6. Après avoir été traité par le Handler, il passe par plusieurs événements Pipeline et se termine par EndRequest.
7. Réponse de sortie.

Si vous souhaitez effectuer une réécriture d'URL dans une application ASP.NET, vous appelez généralement la méthode RewritePath de HttpContext dans l'événement BeginRequest pour repositionner la requête sur une URL cible. Par exemple, nous pouvons remplacer la méthode Application_BeginRequest dans Global.asax pour obtenir ceci :

La raison pour laquelle la réécriture est effectuée dans BeginRequest est que cet événement est le premier déclenché parmi tous les événements du Pipeline. Après le repositionnement à ce stade, certaines propriétés du HttpContext actuel ont également changé en conséquence (telles que HttpContext.Request.Path). De cette façon, la logique du gestionnaire des événements Pipeline suivants sera affectée. Par exemple, lorsque les autorisations doivent être déterminées en fonction d'un répertoire, le chemin « localisé » sera utilisé à la place de la requête reçue par ASP.NET. Naturellement, le changement le plus "significatif" est le choix du gestionnaire. Par exemple, dans l'exemple ci-dessus, nous déplaçons la requête vers le fichier "CustomerList.aspx", afin que le moteur ASP.NET sélectionne System.Web.UI. correspondant à *.aspx La classe PageHandlerFactory gère les requêtes.

classe publique Global : System.Web.HttpApplication .
{
    protected void Application_BeginRequest (expéditeur de l'objet , EventArgs e)
    {
        Contexte HttpContext = HttpContext .Current ;
 
        if (context.Request.Path.Equals( "/Clients" ,
            StringComparison .InvariantCultureIgnoreCase))
        {
            context.RewritePath( "~/CustomerList.aspx" );
        }
    }
}

En guise de dernière remarque, deux concepts doivent être distingués, à savoir "ASP.NET Pipeline" et "Web Forms". Les deux sont des modèles importants dans ASP.NET, mais les différences restent très grandes :

• Pipeline ASP.NET : Comme toute requête reçue par une application ASP.NET, elle sera traitée via ce "pipeline". Il s'agit d'un modèle de niveau ASP.NET.
• Formulaires Web : lors de l'exécution du pipeline ASP.NET, l'une des étapes consiste à sélectionner un gestionnaire approprié (ou HandlerFactory) pour gérer la demande. S'il s'agit d'une page aspx, ASP.NET choisira la classe System.Web.UI.PageHandlerFactory, dans laquelle le modèle WebForms est finalement formé .

En fait, le mot « forme » dans la phrase ci-dessus n’est peut-être pas exact. Parce que Web Forms devrait probablement être un moteur d'exécution et un modèle pouvant être utilisé indépendamment, et System.Web.UI.PageHandlerFactory utilise uniquement ce modèle. Lorsque nous écrivons des applications ASP.NET, nous pouvons utiliser ce modèle ailleurs en fonction de nos besoins. Par exemple, dans l'article « Technique : Utilisation du contrôle utilisateur pour la génération HTML », nous utilisons ascx comme modèle dans un gestionnaire générique pour générer du contenu.