ASP.NET MVC eurl.axd errori

Question

Mediante i seguenti passaggi:

(. Ho controllato this similar post, che non risolve il mio problema)

1. In Windows Server 2003/IIS6, creo un nuovo sito chiamato "testapp"
2. In VS2010, creo una nuova applicazione ASP.NET MVC 2.

3. aggiungo una vista chiamata "Info" con il seguente codice:

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

Oltre alle intestazioni standard vedo questo:

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

Sto usando Helicon ISAPI Rewrite 3, che sta generando l'intestazione "X-REWRITE-URL".

Il mio problema è questo: da dove viene il /eurl.axd?....? Ho visto this article, ma poiché si tratta di un'app vuota in una nuova cartella con un nuovo pool di app, NON ci sono 2.0. * App in esecuzione all'interno di questa cartella web. Non ci sono cartelle virtuali che puntano a un'altra directory, ecc. Il sito è configurato per ASP.NET 4.0, che è registrato correttamente.

Il problema è che eurl.axd sta avvitando i parametri nei miei percorsi MVC.

Le opzioni nell'articolo "ASP.NET 4.0 Breaking Changes" non funzionano per me, perché non ci sono componenti 2.0 in questa app e ho bisogno di utilizzare URL senza estensione.

Aggiornamento Ho appena notato che System.Web.MVC nel GAC è la versione 2.0.0.0. Questo dovrebbe essere stato aggiornato a 4.0 con l'installazione di VS2010 e del framework 4.0?

Non capisco perché vedo questo errore con un'applicazione ASP.NET MVC 2 predefinita. Aiuto!!

Aggiornamento 2/2011 - Risolto

aver finalmente provato la disabilitazione degli URL senza estensione tramite l'hack del Registro, il problema è scomparso. Trovo controsenso che disabilitare gli URL senza estensioni faccia funzionare gli URL senza estensioni (con la mappatura dei caratteri jolly in IIS6), ma prenderò ciò che posso ottenere.

Aggiornamento 12/2014

(Merry | Felice | Peaceful) (Natale | Hanukkah | Kwanzaa | dicembre).

Ho dimenticato di menzionare che ogni altro aggiornamento di Windows ha annullato la modifica del registro. Questo è apparso come problemi strani in cui una richiesta di http://site.dom/bob avrebbe esito negativo, mentre il http://site.dom/bob/ avrebbe avuto successo. Divertiti! (Notare la barra finale.)

Answer 1

Questo è parte dell'approccio di Microsoft per abilitare gli URL senza estensione per essere gestiti da ASP.NET v4 per impostazione predefinita in IIS 6.È descritto qui nel documento ASPNET V4 Breaking Changes. (Cerca in quel documento per eurl.axd). Questo succede solo con ASPNET v4.

ciò che accade è:

1. aspnet_filter.dll, il filtro ISAPI globale che implementa ASPNET (clic destro cartella Siti Web> Proprietà per vederlo) ispeziona ogni URL in entrata. Per quegli URL che non hanno estensione, ASPNET quindi manipola l'URL per inserire /eurl.axd/some-long-number in esso. In realtà il numero lungo è un guid senza trattini.

2. Il tuo rewriter URL, un filtro ISAPI specifico del sito, viene eseguito accanto e vede l'URL alterato. Perché le regole non si aspettano gli URL con quella sequenza strana iniettato in loro, il filtro di riscrittura non gestisce correttamente e l'utente probabilmente finisce con un 404.

Questo avverrà con qualsiasi filtro riscrittura - Helicon ISAPI_Rewrite, IIRF, ecc. - se installato con IIS6 e ASPNET v4. Può anche accadere con altri filtri ISAPI, quelli che non sono esplicitamente riscrittori.

Ciò che Microsoft destinato ciò accada:

1. aspnet_filter.dll ISAPI filtro aggiunge /eurl.axd/some-long-number a un URL senza estensione. (Se l'URL ha un'estensione, lascia da solo, risparmiando il colpo di performance dal codice gestito.) Questo è solo per ottenere ".axd" lì così IIS6, nella sua configurazione predefinita, si assocerà all'ISAPI aspnet_isapi.dllestensione (applicazione).

2. Il aspnet_isapi.dll ISAPI applicazione raccoglie la richiesta, unmangles l'URL rimuovendo il /eurl.axd/some-long-number, e lo passa al codice ASP.NET progettato per gestire extensionlesses URL. Quel codice gestisce la richiesta e non si rende conto che il /eurl.axd/some-long-number- numero di shenanigans è mai accaduto.

Microsoft ha omesso di considerare che cosa accadrebbe per i filtri ISAPI URL-controllo che si trovano tra i passaggi 1 e 2. Le ASP.NET 4 note di rilascio sono installate applicazioni una nota su .NET 2.0 che causano questo errore; questo è solo un modo in cui può accadere.

avete alcune opzioni:

• utilizzare la chiave di registro per girare appena fuori. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0> DWORD EnableExtensionlessUrls a 0, quindi riavviare IIS.

• Effettua la riscrittura dell'URL all'interno della pipeline ASP.NET. (Ovviamente puoi solo riscrivere le richieste gestite in questo caso.)

• Installa il tuo filtro URL ISAPI riscrivibile a livello globale con una priorità superiore a aspnet_filter.dll. Mi sembra un dolore.

• Configurare il sito Web per utilizzare ASPNET v2, anziché ASPNET v4.

• inserire una regola nel proprio rewriter per ignorare completamente gli URL con eurl.axd in loro. Questo potrebbe essere semplice come
  RewriteRule eurl\.axd -

Io uso la chiave di registro e funziona bene per me.

Buona fortuna!

AGGIORNAMENTO 2011-08-10: Sembra che gli Aggiornamenti di Windows che supportano .NET Framework reimpostino la chiave di registro e debbano essere riapplicati.

Modifica 2012-02-17 Abbiamo avuto questo problema e il nostro team ha trascorso diverse ore a risolvere il problema prima che qualcuno scoprisse che questo sepolto nei commenti completava la soluzione per noi. "Nota che per Wow64 (vale a dire, processo di lavoro a 32 bit in esecuzione su sistema operativo a 64 bit), questa chiave di registro deve essere impostata su HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ ASP.NET \ 4.0.30319.0 \ EnableExte nsionlessUrls."

Answer 2

Io uso il seguente espressione regolare come primo regola con Ionics Isapi masterizzatore per i siti web in esecuzione su ASP.NET 4 su IIS 6 per ovviare ai problemi causati dalla breaking change introdotta con ASP.NET 4:

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

Questo mi consente di utilizzare nuovamente gli URL senza estensione.

Si noti che il secondo gruppo acquisisce la querystring se presente e la restituisce all'URL riscritto.

E sì, è a feature, not a bug.

Answer 3

Ho avuto un problema simile e ho trovato una soluzione tramite il nostro provider di moduli ISAPI Rewrite. Ho documentato il risultato e la soluzione: http://www.vanadiumtech.com/OurBlog/post/2011/08/12/Cause-of-eurlaxd.aspx