Physischer Ordner unterbricht ASP.NET-URL-Routing unter IIS Express

IIS Express erzeugt 403.14 Forbidden -Fehler, wenn eine URL, die andernfalls über das ASP.NET-URL-Routing behandelt würde, einem physischen Ordner in meinem ASP.NET-Projekt entspricht. (Der Ordner enthält nur Code, und zufälligerweise stimmt der Ordnername mit der URL einer Seite überein; meine URL-Struktur wird dynamisch von einer Datenbank bestimmt, und Benutzer können diese Struktur bearbeiten, obwohl ich meinen Projektordner einfach umbenennen könnte. im Allgemeinen kann ich diese Art von Kollision nicht verhindern.)

Dies scheint zu geschehen, weil die DirectoryListingModule eingreift, um die Anfrage zu bearbeiten, und dann sofort fehlschlägt, weil das Durchsuchen des Verzeichnisses deaktiviert ist. Ich habe versucht, dies zu entfernen:

Dadurch wird die standardmäßige StaticFile -Handlerkonfiguration mit modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" entfernt und durch eine Konfiguration ersetzt, die nur die gewünschte Funktion bietet. (Ich möchte statische Dateidienste, aber ich brauche keine Verzeichnisliste oder Standarddokumente in dieser App.) Aber der Effekt scheint zu sein, dass IIS dann eine vollständig leere (0 Byte) Antwort (mit einem 200-Status) erzeugt, wenn ich treffe die beleidigende Seite.

Als Nächstes habe ich versucht, den StaticFile -Handler so zu konfigurieren, dass er nur die spezifischen physischen Ordner behandelt, die ich zur Verfügung stellen möchte:

Aber wenn ich die anstößige URL treffe, erzeugt dies einen 404.4 - Not found Fehler mit einer Nachricht von The resource you are looking for does not have a handler associated with it. . (Die detaillierten Fehlerinformationen auf der Fehlerseite geben an, dass wir uns im IIS Web Core -Modul befinden, während der MapRequestHandler -Benachrichtigung der Handler Not yet determined ist und es einen Fehlercode von 0x80070002 gibt, der ein COM-HRESULT ist das entspricht dem Fehler Win32 ERROR_FILE_NOT_FOUND .)

Die verwirrende Sache ist, dass es nicht einmal stört, ASP.NET zu fragen, ob es einen Handler dafür hat. IIS scheint ganz von selbst zu entscheiden, dass es definitiv keinen Handler gibt.

Dies geschieht nur, wenn ein Ordner mit der URL übereinstimmt. Alle anderen Ressourcen mit dynamisch bestimmten URLs funktionieren einwandfrei - IIS fragt ASP.NET nach einem Handler, der Routing-Mechanismus von ASP.NET wird normal ausgeführt, und wenn die URL einer meiner dynamisch definierten Seiten entspricht, funktioniert alles einwandfrei. Es ist nur das Vorhandensein eines physischen Ordners, der das alles verhindert.

Ich kann sehen, dass IIS dies tut, weil ich eine der Fehlerseiten im IIS-Stil für dieses 404 erhalte, und sie haben ein unverwechselbares Design, das sich sehr von dem von ASP.NET erzeugten 404 unterscheidet. (Wenn ich versuche, zu einer URL zu navigieren, die weder einem physischen Ordner noch einer dynamischen Ressource entspricht, erhalte ich eine 404-Seite, die von ASP.NET generiert wird. Daher übergibt IIS Anfragen normalerweise an ASP.NET, aber an IIS steht definitiv diesen problematischen Ressourcen im Wege.)

Ich habe versucht, das in meinem <system.WebServer> hinzuzufügen, falls das Problem war, dass IIS entschieden hat, dass Anfragen, die physischen Ordnern entsprechen, die Bedingung managedHandler nicht erfüllen:

Aber das scheint nicht zu helfen - es bringt immer noch kein ASP.NET-Routing für URLs mit sich, die physischen Ordnern entsprechen. In jedem Fall wäre es suboptimal - ich würde es vorziehen, wenn keine verwalteten Handler für den Inhalt ausgeführt würden, den ich definitiv als statischen Inhalt behandeln möchte. Ich möchte effektiv, dass ASP.NET URL-Routing als Backstop verwendet wird - ich möchte nur, dass es ins Spiel kommt, wenn die URL definitiv nicht auf statischen Inhalt verweist.

Ich verstehe nicht, warum ASP.NET nicht einmal ASP.NET fragt, was es in diesem Szenario denkt. Warum ruft es während der Phase MapRequestHandler nicht in ASP.NET auf, wenn ein physischer Ordner zufällig mit der URL übereinstimmt?