2010-06-21 21 views
30

wykonując następujące kroki:ASP.NET MVC eurl.axd błędy

(. Sprawdziłem this similar post, która nie rozwiązuje mojego problemu)

  1. W systemie Windows Server 2003/IIS6, tworzę nowa strona o nazwie "testapp"
  2. W VS2010 tworzę nową aplikację ASP.NET MVC 2.
  3. dodam widok o nazwie "Info" z następującego kodu:

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

Oprócz standardowych nagłówków widzę tego jednego:

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

Używam Helicon ISAPI Rewrite 3, który generuje nagłówek "X-REWRITE-URL".

Mój problem jest następujący: skąd pochodzi /eurl.axd?....? Widziałem this article, ale ponieważ jest to pusta aplikacja w nowym folderze z nową pulą aplikacji, w tym folderze internetowym nie ma aplikacji 2.0. *. Nie ma wirtualnych folderów wskazujących na inny katalog itp. Witryna jest skonfigurowana dla ASP.NET 4.0, która jest poprawnie zarejestrowana.

Problem polega na tym, że eurl.axd wkręca parametry na moich trasach MVC.

Opcje w artykule "Zmiany w programie ASP.NET 4.0" nie działają dla mnie, ponieważ w tej aplikacji nie ma żadnych składników 2.0 i muszę używać bezinwazyjnych adresów URL.

Aktualizacja Właśnie zauważyłem, że System.Web.MVC w GAC jest wersja 2.0.0.0. Czy należy to zaktualizować do wersji 4.0 przy instalacji VS2010 i wersji 4.0?

Nie rozumiem, dlaczego widzę ten błąd w domyślnej aplikacji ASP.NET MVC 2. Wsparcie!!

Aktualizacja 2/2011 - Rozwiązane

Mając wreszcie próbował wyłączyć bez rozszerzeń adresów poprzez hack rejestru, problem zniknął. Uważam za sprzeczne z intuicją, że wyłączanie adresów URL bez rozszerzenia powoduje, że działają bez rozszerzenia adresów URL (z mapowaniem wieloznacznym w IIS6), ale weźmiemy to, co mogę dostać.

Aktualizacja 12/2014

(Wesołych | Szczęśliwy | Pokojowe) (Boże Narodzenie | Chanuka | Kwanzaa | grudnia).

Zapomniałem wspomnieć, że każda inna aktualizacja systemu Windows nuked zmiany rejestru. Wyglądało to jak dziwne problemy, gdy żądanie do http://site.dom/bob zakończyło się niepowodzeniem, podczas gdy http://site.dom/bob/ zakończyłoby się sukcesem. Baw się dobrze! (Zwróć uwagę na końcowy ukośnik.)

Odpowiedz

43

Jest to część podejścia Microsoftu do włączenia adresów URL bez rozszerzenia, które mają być obsługiwane przez ASP.NET v4 domyślnie w IIS 6.Jest to opisane w dokumencie ASPNET V4 Breaking Changes. (Wyszukaj w tym dokumencie dla eurl.axd). Dzieje się tak tylko w ASPNET v4.

Co się dzieje:

  1. aspnet_filter.dll, globalny filtr ISAPI, który implementuje ASPNET (kliknij prawym przyciskiem myszy folder Witryny sieci Web> Właściwości, aby go zobaczyć) sprawdza każdy link przychodzący. W przypadku adresów URL, które nie mają żadnego rozszerzenia, ASPNET wykreśla następnie adres URL, aby wstawić do niego /eurl.axd/some-long-number. W rzeczywistości długi numer to przewodnik bez kresek.

  2. Twój program do przepisywania adresów URL, specyficzny dla witryny filtr ISAPI, działa dalej i widzi zmanipulowany adres URL. Ponieważ twoje zasady nie oczekiwać URL z tej dziwnej kolejności wtryskiwanego do nich, Twój filtr przepisać nie obsługiwać go prawidłowo, a użytkownik prawdopodobnie kończy się z 404.

Stanie się tak z każdym filtrem przepisywania - Helicon ISAPI_Rewrite, IIRF itp. - po zainstalowaniu z IIS6 i ASPNET v4. Może się również zdarzyć w przypadku innych filtrów ISAPI - tych, które nie są jawnie przepisującymi.

Co Microsoft przeznaczone wydarzy:

  1. aspnet_filter.dll ISAPI filtr dodaje /eurl.axd/some-long-number do adresu URL bez rozszerzeń. (Jeśli URL ma w sobie rozszerzenie, pozostawia je w spokoju, oszczędzając wydajność uderzając w zarządzany kod.) To jest po to, aby uzyskać ".axd", więc IIS6, w domyślnej konfiguracji, zostanie odwzorowane na aspnet_isapi.dll ISAPI rozszerzenie (aplikacja).

  2. aspnet_isapi.dll ISAPI aplikacja odbiera żądanie, unmangles URL usuwając /eurl.axd/some-long-number i przekazuje go do kodu ASP.NET zaprojektowany do obsługi extensionlesses adresy URL. Ten kod obsługuje żądanie i nie zdaje sobie sprawy, że zdarzają się shenanigany /eurl.axd/some-long-number.

Microsoft nie wziął pod uwagę tego, co by się stało, do URL-kontroli filtrów ISAPI, które siedzą między etapami 1 i 2. ASP.NET 4 release notes posiada notatkę o .NET 2.0 aplikacji przyczyną tego błędu; to tylko jeden z możliwych sposobów.

Masz kilka opcji:

  • użyć klucza rejestru, aby po prostu go wyłączyć. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0> DWORD EnableExtensionlessUrls do 0, a następnie uruchom ponownie IIS.

  • Przepiszanie adresów URL w obrębie potoku ASP.NET. (Oczywiście w tym przypadku można tylko przepisać zarządzone żądania).

  • Zainstaluj program do przepowiadania adresów URL filtru ISAPI na poziomie globalnym z priorytetem wyższym niż aspnet_filter.dll. Brzmi jak ból dla mnie.

  • Skonfiguruj witrynę do używania ASPNET v2 zamiast ASPNET v4.

  • wstawić regułę w swoim przeszukiwaczu, aby całkowicie ignorować adresy URL z eurl.axd w nich. To może być tak proste, jak
    RewriteRule eurl\.axd -

użyć klucza rejestru i działa dobrze dla mnie.

Powodzenia!

UPDATE 2011-08-10: Wygląda na to, że aktualizacje systemu Windows, które obsługują system .NET Framework, resetują klucz rejestru i muszą zostać ponownie zastosowane.

Edit 2012-02-17 Mieliśmy ten problem, a nasz zespół spędził kilka godzin pracy problem, zanim ktoś znalazł ten pochowany w komentarzach zakończyła rozwiązanie dla nas. "Należy zauważyć, że dla Wow64 (tj. Dla 32-bitowego procesu roboczego działającego w 64-bitowym systemie operacyjnym) ten klucz rejestru musi być ustawiony na HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ ASP.NET \ 4.0.30319.0 \ EnableExte nsionlessUrls."

+0

Dzięki za szczegółową odpowiedź. Pytanie - czy wyłączanie adresów URL bez rozszerzenia nie koliduje z routingiem MVC? –

+0

Moje trasy MVC mają w nich ".aspx", ale każde ". Coś", które jest mapowane do aplikacji ASP.NET ISAPI, działałoby. Np. "/store.aspx/controller/action/id" –

+0

Powinienem dodać ... nadal możesz mieć bez rozszerzenia adresów URL za pomocą mapowania wieloznacznego, tak aby wszystko przechodziło przez aplikację ISAPI ASP.NET. Tak właśnie zrobili ludzie w V2. Ale miało to implikacje związane z perfekcją. Schemat, który stworzyli dla V4 z filtrem, był próbą domyślnego uzyskania bezstratnych adresów URL w IIS6, ponieważ tylko adresy URL bez rozszerzenia są przepisywane, aby uzyskać .axd, i nie wszystko musi iść do ASP. Aplikacja NET ISAPI. Jeśli przepisywanie adresów URL oparte na ISAPI za pomocą narzędzi takich jak IIRF nie jest dla ciebie ważne, możesz równie dobrze zaakceptować ustawienia domyślne. –

17

używam następujące regex jako pierwszej reguły z lonics ISAPI rewriter do stron internetowych działa na ASP.NET 4 na IIS 6 do rozwiązania problemów powodowanych przez breaking change wprowadzono ASP.NET 4:

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

Pozwolę sobie ponownie użyć bezoptymowych adresów URL.

Należy zauważyć, że druga grupa przechwytuje zapytanie, jeśli jest obecne i przywraca je do przepisanego adresu URL.

I tak, to a feature, not a bug.

+1

Świetne, czyste rozwiązanie! – cspolton

+1

To działało również dla nas z Helicon ISAPI_REWRITE. Dodaliśmy flagę NC: – palehorse

+0

Perfect !! Dzięki – jaywon