Errores ASP.NET MVC eurl.axd

asp.net-mvc .net-4.0

Question

Usando los siguientes pasos:

(He revisado esta publicación similar , que no resuelve mi problema).

1. Bajo Windows Server 2003 / IIS6, creo un nuevo sitio llamado "testapp"
2. En VS2010, creo una nueva aplicación ASP.NET MVC 2.

3. Añado una vista llamada "Información" con el siguiente código:

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

Además de los encabezados estándar, veo este:

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

Estoy utilizando Helicon ISAPI Rewrite 3 , que está generando el encabezado "X-REWRITE-URL".

Mi problema es este: ¿de dónde viene el /eurl.axd?.... ? He visto este artículo , pero dado que se trata de una aplicación en blanco en una nueva carpeta con un nuevo grupo de aplicaciones, NO hay aplicaciones 2.0. * Que se ejecutan dentro de esta carpeta web. No hay carpetas virtuales apuntando a otro directorio, etc. El sitio está configurado para ASP.NET 4.0, que está registrado correctamente.

El problema es que el eurl.axd está atornillando con parámetros en mis rutas MVC.

Las opciones del artículo "ASP.NET 4.0 Breaking Changes" no me funcionan, porque no hay ningún componente 2.0 en esta aplicación, y necesito usar URLs sin extensión.

Actualización Acabo de notar que System.Web.MVC en el GAC es la versión 2.0.0.0. ¿Debería haberse actualizado a 4.0 con la instalación de VS2010 y el marco 4.0?

No entiendo por qué veo este error con una aplicación ASP.NET MVC 2 predeterminada. ¡¡Ayuda!!

Actualización 2/2011 - Resuelto

Finalmente, al intentar deshabilitar las URL sin extensión a través del hack de registro, el problema desapareció. Me parece contrario a lo intuitivo que deshabilitar las URL sin extensión hace que las URL sin extensión funcionen (con la asignación de caracteres comodín en IIS6), pero tomaré lo que pueda obtener.

Actualización 12/2014

(Feliz | Feliz | Pacífica) (Navidad | Hanukkah | Kwanzaa | Diciembre).

Olvidé mencionar que cualquier otra actualización de Windows interrumpió el cambio de registro. Esto apareció como un problema extraño donde una solicitud a http://site.dom/bob fracasaría, mientras que http://site.dom/bob/ tendría éxito. ¡Que te diviertas! (Observe la barra inclinada).

Answer 1

Esto es parte del enfoque de Microsoft para permitir que las direcciones URL sin extensión sean manejadas por ASP.NET v4 de manera predeterminada en IIS 6. Se describe aquí en el documento de cambios de ruptura de ASPNET V4 . (Busque en ese documento para eurl.axd). Esto sucede solo con ASPNET v4.

Lo que ocurre es:

1. aspnet_filter.dll , el filtro ISAPI global que implementa ASPNET (haga clic con el botón derecho en la carpeta Sitios Web> Propiedades para verlo) inspecciona cada url entrante. Para aquellas URL que no tienen extensión, ASPNET modifica la URL para insertar /eurl.axd/some-long-number en ella. En realidad, el número largo es un guid sin guiones.

2. Su reescritura de URL, un filtro ISAPI específico del sitio, se ejecuta a continuación y ve la URL destrozada. Debido a que sus reglas no esperan URL con esa extraña secuencia inyectada en ellas, su filtro de reescritura no lo maneja adecuadamente, y el usuario probablemente termine con un 404.

Esto sucederá con cualquier filtro de reescritura - Helicon ISAPI_Rewrite, IIRF, etc. - cuando se instale con IIS6 y ASPNET v4. También puede suceder con otros filtros ISAPI, aquellos que no son reescritura explícita.

Lo que Microsoft pretendía que sucediera:

1. aspnet_filter.dll filtro aspnet_filter.dll ISAPI agrega /eurl.axd/some-long-number a una URL sin extensión. (Si la URL tiene una extensión, la deja sola, ahorrando el impacto del rendimiento al golpear el código administrado). Esto es solo para obtener ".axd" allí, por lo que IIS6, en su configuración predeterminada, se asignará a aspnet_isapi.dll Extensión ISAPI (aplicación).

2. La aplicación ISAPI aspnet_isapi.dll recoge la solicitud, desmarca la URL eliminando el /eurl.axd/some-long-number y lo pasa al código ASP.NET diseñado para manejar las URL sin extensión. Ese código maneja la solicitud y no se da cuenta de que las shenanigans /eurl.axd/some-long-number ocurrieron alguna vez.

Microsoft no consideró lo que sucedería con los filtros ISAPI de inspección de URL que se encuentran entre los pasos 1 y 2. Las notas de la versión ASP.NET 4 tienen una nota sobre las aplicaciones .NET 2.0 que causan este error; esa es solo una forma en que puede suceder

Tienes algunas opciones:

• Usa la clave de registro para apagarlo. HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/ASP.NET/4.0.30319.0 > DWORD EnableExtensionlessUrls a 0 , luego reinicie IIS.

• Realice la reescritura de URL dentro de la interconexión de ASP.NET. (Obviamente, solo puede reescribir solicitudes administradas en este caso).

• Instale su reescritura de URL de filtro ISAPI en el nivel global con una prioridad superior a aspnet_filter.dll . Me parece un dolor.

• Configure el sitio web para utilizar ASPNET v2, en lugar de ASPNET v4.

• inserte una regla en su reescritura para ignorar por completo las URL con eurl.axd en ellas. Esto podría ser tan simple como
  RewriteRule eurl/.axd -

Uso la clave de registro y funciona bien para mí.

¡Buena suerte!

ACTUALIZACIÓN 2011-08-10: Parece que las Actualizaciones de Windows que dan servicio a .NET Framework restablecen la clave de registro y deben volver a aplicarse.

Edit 2012-02-17 Tuvimos este problema y nuestro equipo pasó varias horas trabajando el problema antes de que alguien lo descubriera en los comentarios y completó la solución para nosotros. "Tenga en cuenta que para Wow64 (es decir, un proceso de trabajo de 32 bits que se ejecuta en un sistema operativo de 64 bits), esta clave de registro debe configurarse en HKEY_LOCAL_MACHINE / SOFTWARE / Wow6432Node / Microsoft / ASP.NET / 4.0.30319.0 / EnableExte‌ nsionlessUrls".

Answer 2

Me encontré con un problema similar y encontré una solución a través de nuestro proveedor de módulos ISAPI Rewrite. Documenté el hallazgo y la solución: http://www.vanadiumtech.com/OurBlog/post/2011/08/12/Cause-of-eurlaxd.aspx

Answer 3

Uso la siguiente expresión regular como primera regla con Ionics Isapi Rewriter para los sitios web que se ejecutan en ASP.NET 4 en IIS 6 para solucionar los problemas causados ​​por el cambio de ruptura introducido con ASP.NET 4:

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

Esto me permitió usar de nuevo urls sin extensión.

Tenga en cuenta que el segundo grupo captura la cadena de consulta si está presente y la restituye a la url reescrita.

Y sí, es una característica, no un error .