ASP.NET MVC eurl.axd errores

Question

utilizando los siguientes pasos:

(. He comprobado this similar post, que no resuelve mi problema)

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

3. añado una vista denominada "Info" 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 las cabeceras estándar veo éste:

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

Estoy usando Helicon ISAPI Rewrite 3, que genera el encabezado "X-REWRITE-URL".

Mi problema es este: ¿de dónde viene el /eurl.axd?....? He visto this article, 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á atornillándose con parámetros en mis rutas de MVC.

Las opciones en el artículo "Cambios de última hora de ASP.NET 4.0" realmente 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 haber sido actualizado a 4.0 con la instalación de VS2010 y el framework 4.0?

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

actualización 2/2011 - Resuelta

Tener finalmente intentado desactivar URL sin extensión a través del corte del registro, el problema desapareció. Encuentro contra-intuitivo que deshabilitar las URL sin extensión hace que las URL sin extensión funcionen (con la asignación de comodines en IIS6), pero tomaré lo que pueda obtener.

actualización 12/2014

(Feliz | Feliz | Pacífica) (Navidad | Jánuca | Kwanzaa | diciembre).

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

Answer 1

Esto es parte del enfoque de Microsoft para permitir que ASP.NET v4 administre direcciones URL sin extensión de forma predeterminada en IIS 6.Se describe aquí en el documento ASPNET V4 Breaking Changes. (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 derecho en la carpeta Sitios Web> Propiedades verla) inspecciona cada URL entrante. Para las direcciones 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 normas no esperan URL con esa secuencia extraña inyectado en ellos, su filtro de reescritura no maneja correctamente, y el usuario probablemente termina con un 404.

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

Lo que Microsoft pretende suceda:

1. aspnet_filter.dll ISAPI filtro añade /eurl.axd/some-long-number a una URL sin extensión. (Si la URL tiene una extensión, la deja sola, lo que ahorra rendimiento al golpear el código administrado.) Esto es solo para obtener ".axd" ahí para que IIS6, en su configuración predeterminada, se asigne al aspnet_isapi.dll ISAPI extensión (aplicación).

2. El aspnet_isapi.dll ISAPI aplicación recoge la petición, unmangles la URL mediante la eliminación de la /eurl.axd/some-long-number, y lo pasa al código ASP.NET diseñado para manejar extensionlesses URLs. 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 tuvo en cuenta lo que sucedería a los filtros ISAPI-URL inspección que se sientan entre los pasos 1 y 2. Las notas de la versión 4 ASP.NET tener aplicaciones una nota sobre .NET 2.0 causando este error; esa es solo una forma en que puede suceder.

usted tiene algunas opciones:

• utilizar la clave del registro para simplemente apagarla. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0> DWORD EnableExtensionlessUrls a 0, luego reinicie IIS.

• 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 del filtro ISAPI a nivel mundial 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.

• inserta una regla en tu reescritura para ignorar por completo las URL con eurl.axd en ellos. Esto podría ser tan simple como
  RewriteRule eurl\.axd -

utilizo 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 en el problema antes de que alguien encontrara esto enterrado en los comentarios completados la solución para nosotros. "Tenga en cuenta que para Wow64 (es decir, el proceso de trabajo de 32 bits que se ejecuta en el sistema operativo de 64 bits), esta clave de registro debe establecerse en HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ ASP.NET \ 4.0.30319.0 \ EnableExte nsionlessUrls."

Answer 2

utilizo la siguiente expresión regular como primera regla con Ionics Isapi Regrabadora para los sitios web que se ejecuta en ASP.NET 4 en IIS 6 para remediar los problemas causados ​​por el breaking change introducido con ASP.NET 4:

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

Deje que vuelva a utilizar las URL 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 a feature, not a bug.

Answer 3

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