Pourquoi le routage ASP.NET est-il prioritaire sur la section web.config Http Handlers?

Question

Notre boutique intègre ASP.NET MVC dans une grande application Web qui utilise des gestionnaires HTTP tiers personnalisés définis dans web.config sous system.webServer \ handlers. Tirer parti des gestionnaires HTTP de cette façon a été formidable pour nous car nous n'avons pas besoin de recompiler l'application ou d'avoir la page du gestionnaire sur le disque quelque part dans la portée web pour chaque instance du produit.

Est-il vraiment nécessaire d'ajouter explicitement Ignorer les Routes dans notre global.asax afin que le Runtime puisse honorer les Handlers définis dans web.config? J'aurais pensé que Web.Routing serait appelé après les gestionnaires définis dans system.webServer \ handlers ont été vérifiés (pas l'inverse).

Nous utilisons une conception modulaire qui permet d'ajouter/supprimer des gestionnaires de web.config lorsque des fonctionnalités sont ajoutées. Avec l'introduction du routage MVC, il apparaît que nous devons ajouter des routes ignorées dans le fichier global.asax pour chaque gestionnaire possible défini dans web.config.

Notez que le fichier réel de ces gestionnaires n'existe pas sur le disque: ils sont virtuels et incorporés dans un assembly. Voici un exemple d'un gestionnaire 3ème partie qui exige désormais une explicite Ignorer la route dans global.asax:

<system.webServer> 
    <handlers> 
      <!-- telerik radcontrols --> 
      <add name="TelerikDialogHandler" verb="*" path="Telerik.Web.UI.DialogHandler.aspx" type="Telerik.Web.UI.DialogHandler, Telerik.Web.UI, Version=2009.1.402.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4"></add> 
    </handlers> 
</system.webServer> 

Pour le compte rendu si vous utilisez System.Web.Routing vous devez inclure Ignorer Routes pour Handlers Http spécifiées dans le Web .Config? Ou peut-être que je fais quelque chose de mal?

Answer 1

Le traitement des demandes ASP.NET est basé sur un modèle de pipeline dans lequel ASP.NET transmet des demandes http à tous les modules du pipeline. Chaque module reçoit la requête http et en a le contrôle total. Une fois que la requête passe à travers tous les modules HTTP, elle est finalement traitée par un gestionnaire HTTP. Le gestionnaire HTTP effectue un traitement sur celui-ci, et le résultat passe à nouveau à travers les modules HTTP dans le pipeline.

Je pense que la meilleure façon de penser à cela est que HttpModule est un filtre qui ajoute ou soustrait quelque chose de l'objet requête lorsqu'un événement se produit et que HttpHandler est un processeur qui sert réellement la requête. Le cycle de vie de la demande ASP.NET est configuré de telle sorte que tous les filtres sont appliqués à la demande avant que ne se produise.