ASP.NET MVC erreurs eurl.axd

Question

En utilisant les étapes suivantes :

(J'ai consulté ce post similaire, qui ne résout pas mon problème.)

1. Sous Windows Server 2003/IIS6, je crée un nouveau site appelé "testapp"
2. Dans VS2010, je crée une nouvelle application ASP.NET MVC 2.

3. Je ajoute une vue appelée "Info" avec le code suivant :

   System
   
   Demande
   
   <%
       foreach (string key in Request.Headers)
       {
           Response.Write(string.Format("{0}={1}"
                   , key
                   , Request.Headers[key])
                   );
       }
   
   %>

En plus des en-têtes standard, je vois celui-ci :

   X-REWRITE-URL=/home/info/eurl.axd/e3299f29f8043d4f8a27e0f1d0c40971

J'utilise Helicon ISAPI Rewrite 3, qui génère l'en-tête "X-REWRITE-URL".

Mon problème est le suivant : d'où vient le /eurl.axd?.... ? J'ai vu cet article, mais comme c'est une application vide dans un nouveau dossier avec un nouveau pool d'applications, il n'y a AUCUNE application 2.0.* en cours d'exécution dans ce dossier Web. Il n'y a pas de dossiers virtuels pointant vers un autre répertoire, etc. Le site est configuré pour ASP.NET 4.0, qui est correctement enregistré.

Le problème est que le eurl.axd perturbe les paramètres de mes routes MVC.

Les options de l'article "ASP.NET 4.0 Breaking Changes" ne fonctionnent pas vraiment pour moi, car il n'y a pas de composants 2.0 dans cette application, et j'ai besoin d'utiliser des URL sans extension.

Mise à jour Je viens de remarquer que System.Web.MVC dans le GAC est en version 2.0.0.0. Aurait-il dû être mis à jour en 4.0 avec l'installation de VS2010 et le framework 4.0 ?

Je ne comprends pas pourquoi je vois cette erreur avec une application MVC 2 ASP.NET par défaut. Aidez-moi!!

Mise à jour 2/2011 - Résolu

Après avoir enfin essayé de désactiver les URL sans extension via le hack de registre, le problème a disparu. Je trouve contre-intuitif que la désactivation des URL sans extension rende les URL sans extension fonctionnels (avec la correspondance de joker dans IIS6), mais je prends ce que je peux avoir.

Mise à jour 12/2014

(Joyeux|Heureux|Paisible) (Noël|Hanoukkah|Kwanzaa|Décembre).

J'ai oublié de mentionner que chaque autre mise à jour de Windows réinitialisait le changement de registre. Cela se manifestait par des problèmes étranges où une requête vers http://site.dom/bob échouerait, tandis que http://site.dom/bob/ réussirait. Amusez-vous ! (Remarquez le slash final.)

Answer 1

Cela fait partie de l'approche de Microsoft pour permettre aux URL sans extension d'être gérées par défaut par ASP.NET v4 dans IIS 6. Cela est décrit ici dans le Document sur les changements d'ASPNET V4. (Recherchez dans ce document pour eurl.axd). Cela se produit uniquement avec ASP.NET v4.

Ce qui se passe est le suivant:

1. aspnet_filter.dll, le filtre ISAPI global qui implémente ASPNET (faites un clic droit sur le dossier Web Sites > Propriétés pour le voir) inspecte chaque URL entrante. Pour les URLs qui n'ont pas d'extension, ASPNET modifie ensuite l'URL pour insérer /eurl.axd/un-long-numéro. En réalité, le long nombre est un GUID sans tirets.

2. Votre réécrivain d'URL, un filtre ISAPI spécifique au site, s'exécute ensuite et voit l'URL modifiée. Comme vos règles ne s'attendent pas à trouver des URLs avec cette séquence étrange injectée dedans, votre filtre de réécriture ne la gère pas correctement, et l'utilisateur se retrouve probablement avec une erreur 404.

Cela se produira avec n'importe quel filtre de réécriture - Helicon ISAPI_Rewrite, IIRF, etc. - lorsqu'ils sont installés avec IIS6 et ASPNET v4. Cela peut également se produire avec d'autres filtres ISAPI - ceux qui ne sont pas explicitement des réécrivains.

Ce que Microsoft avait l'intention de se produire:

1. Le filtre ISAPI aspnet_filter.dll ajoute /eurl.axd/un-long-numéro à une URL sans extension. (Si l'URL a une extension dedans, il la laisse telle quelle, évitant une perte de performance en accédant au code managé.) Cela sert juste à y inclure ".axd" afin que IIS6, dans sa configuration par défaut, puisse mapper vers l'extension ISAPI aspnet_isapi.dll (application).

2. L'application ISAPI aspnet_isapi.dll récupère la requête, démarre l'URL en supprimant /eurl.axd/un-long-numéro, et la transmet au code ASP.NET conçu pour gérer les URLs sans extension. Ce code traite la requête et ne se rend pas compte que les manigances de /eurl.axd/un-long-numéro ont jamais eu lieu.

Microsoft n'a pas pris en considération ce qui se passerait pour les filtres ISAPI inspectant les URL qui se trouvent entre les étapes 1 et 2. Les notes de publication d'ASP.NET 4 mentionnent une note sur les applications .NET 2.0 causant cette erreur; c'est juste une des façons que cela peut se produire.

Vous avez quelques options:

• Utilisez la clé de registre pour simplement le désactiver. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 > DWORD EnableExtensionlessUrls sur 0, puis redémarrez IIS.

• Réécrivez l'URL dans le pipeline ASP.NET. (Évidemment, vous ne pouvez réécrire que les requêtes managées dans ce cas.)

• Installez votre filtre ISAPI réécrivain d'URL au niveau global avec une priorité plus élevée que aspnet_filter.dll. Cela semble être un peu compliqué selon moi.

• Configurez le site Web pour utiliser ASPNET v2, plutôt que ASPNET v4.

• insérez une règle dans votre réécrivain pour ignorer complètement les URLs avec eurl.axd en elles. Cela pourrait être aussi simple que
  RewriteRule eurl\.axd -

J'utilise la clé de registre et cela fonctionne bien pour moi.

Bonne chance!

MISE À JOUR 2011-08-10: Il semble que les mises à jour de Windows qui concernent le Framework .NET réinitialisent la clé de registre, et elle doit être réappliquée.

Mise à jour 2012-02-17 Nous avons eu ce problème et notre équipe a passé plusieurs heures à travailler sur le problème avant que quelqu'un ne trouve cette solution complète enterrée dans les commentaires. "Notez que pour Wow64 (c'est-à-dire, un processus de travailleur 32 bits s'exécutant sur un OS 64 bits), cette clé de registre doit être définie à HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\4.0.30319.0\EnableExte‌​nsionlessUrls."

Answer 2

J'utilise le regex suivant comme règle première avec Ionics Isapi Rewriter pour les sites web fonctionnant sous ASP.NET 4 sur IIS 6 pour remédier aux problèmes causés par le changement introduit avec ASP.NET 4 :

RewriteRule ^(.*)/eurl.axd/[a-f0-9]{32}(.*)$ $1$2

Cela me permet de réutiliser des URL sans extension.

Notez que le deuxième groupe capture la chaîne de requête si présente et la restitue dans l'URL réécrite.

Et oui, c'est une fonctionnalité, pas un bug.

Answer 3

J'ai rencontré un problème similaire et j'ai trouvé une solution grâce à notre fournisseur de module de réécriture ISAPI. J'ai documenté la découverte et la solution : http://www.vanadiumtech.com/OurBlog/post/2011/08/12/Cause-of-eurlaxd.aspx