2013-07-12 20 views
8

IIS Express produkujących 403.14 Forbidden błędy podczas URL, które inaczej byłyby obsługiwane przez ASP.NET URL routingu dzieje odpowiadają fizycznym folderu w moim projekcie ASP.NET. (Folder zawiera tylko kod, i jest to przypadek, że nazwa folderu stanie dopasować URL strony, moja struktura URL jest określany dynamicznie przez bazę danych, a użytkownicy mogą edytować tę strukturę, więc chociaż może po prostu zmienić nazwę mojego folderu projektu, generalnie nie mogę zapobiec występowaniu tego rodzaju kolizji).Folder fizyczny Breaks URL Routing ASP.NET na IIS ekspresowe

Wydaje się, że tak się dzieje, ponieważ DirectoryListingModule wchodzi do obsługi żądania, a następnie natychmiast go zawiedzie, ponieważ przeglądanie katalogów jest wyłączone. Próbowałem usuwając w ten sposób:

<system.webServer> 
    <handlers> 
    <remove name="StaticFile" /> 
    <add name="StaticFile" path="*" verb="*" 
     modules="StaticFileModule" resourceType="Either" requireAccess="Read" /> 
    </handlers> 
</system.webServer> 

który usuwa konfigurację domyślną StaticFile procedury obsługi, która ma modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule", a zastępuje go konfiguracji zapewniającej tylko funkcję chcę. (Chcę statycznego wyświetlania plików, ale nie mam potrzeby wyświetlania w katalogu lub dokumentów domyślnych w tej aplikacji.) Ale efekt wydaje się, że IIS następnie generuje całkowicie pustą (0 bajtową) odpowiedź (ze statusem 200) po trafieniu obraźliwa strona.

Więc następnym, Próbowałem konfigurowania obsługi StaticFile obsługiwać tylko określone foldery fizyczne, które chcę udostępnić:

<system.webServer> 
    <handlers> 
    <remove name="StaticFile" /> 
    <add name="StaticFileCss" path="style/*.css" verb="*" 
     modules="StaticFileModule" resourceType="Either" requireAccess="Read" /> 
    <add name="StaticFileScripts" path="Scripts/*" verb="*" 
     modules="StaticFileModule" resourceType="Either" requireAccess="Read" /> 
    </handlers> 
</system.webServer> 

Ale kiedy uderzy URL przestępstwa, to wtedy powstaje błąd 404.4 - Not found, z wiadomość z The resource you are looking for does not have a handler associated with it.. (Szczegółowe informacje o błędach na stronie błędu informują, że jesteśmy w module IIS Web Core, podczas powiadomienia MapRequestHandler, program obsługi to Not yet determined, i istnieje kod błędu 0x80070002, który jest HRESULT COM, który odpowiada błędowi Win32 ERROR_FILE_NOT_FOUND.)

tajemnicze rzeczą jest to, że nawet nie zadając sobie trudu, aby zapytać, czy ASP.NET ma obsługi dla niego. Wydaje się, że IIS sam decyduje, że zdecydowanie nie ma programu obsługi.

Dzieje się tak tylko wtedy, gdy jest to folder, który pasuje do adresu URL. Wszystkie inne zasoby z dynamicznie określonymi adresami URL działają bez zarzutu - IIS prosi program ASP.NET o obsługę, mechanizm routingu ASP.NET działa normalnie, a jeśli adres URL odpowiada jednej z dynamicznie zdefiniowanych stron, wszystko działa poprawnie. Jest to tylko obecność fizycznego folderu, który uniemożliwia działanie tego wszystkiego.

Widzę, że robię to w IIS, ponieważ dostaję jedną ze stron błędów w stylu IIS dla tego 404 i mają one charakterystyczny design, który bardzo różni się od 404 produkowanych przez ASP.NET. (Jeśli spróbuję przejść do adresu URL, który nie odpowiada ani fizycznemu folderowi, ani do zasobu dynamicznego, generowana jest strona generowana przez ASP.NET. Tak więc zazwyczaj IIS zdecydowanie przekazuje żądania do ASP.NET, ale IIS . jest zdecydowanie się na drodze dla tych problematycznych zasobów)

próbowałem dodając to w moim <system.WebServer>, w przypadku problemem było to, że IIS zdecydował, że wnioski odpowiadające folderów fizycznych nie spełniają managedHandler warunek:

<modules runAllManagedModulesForAllRequests="true"> 

Ale to nie wydaje się, aby pomóc - to nadal nie dostać routing ASP.NET przypadającą dla adresów URL, które odpowiadają foldery fizycznych. W każdym razie byłby on nieoptymalny - wolałbym, aby zarządzane procedury obsługi nie działały dla zawartości, którą zdecydowanie chcę obsłużyć jako treść statyczną. Skutecznie chcę, aby routing adresów URL w ASP.NET był używany jako mechanizm ochronny - chcę tylko, aby był on uruchamiany, jeśli adres URL zdecydowanie nie odnosi się do zawartości statycznej.

Nie rozumiem, dlaczego ASP.NET nie pyta nawet ASP.NET o to, co myśli w tym scenariuszu. Dlaczego nie wywołuje ASP.NET w fazie MapRequestHandler, jeśli istnieje folder fizyczny odpowiadający adresowi URL?

Odpowiedz

3

Po znalezieniu fizycznego pliku lub folderu o tym samym adresie URL co trasa, trasy nie obsłużą żądania, a fizyczny plik zostanie wyświetlony.

Althrough można to zmienić poprzez ustawienie RouteExistingFiles obiekt z RouteCollection obiektu prawdziwej.

Spójrz na stronę MSDN Scenarios when routing is not applied