Ошибка: IIS7 управляемые запросы

В IIS7 мы можем сказать, что модуль должен запускаться для управляемого контента (таким образом, ускоряя обслуживание статического контента):

<modules>
    ...
    <add name="WhateverName"
         type="WhateverType"
         preCondition="managedHandler"
    ...
</modules>

Но. Это прекрасно работает, если в запрошенном URL также есть имя файла (с расширением). Если он пропущен, IIS7 будет считать, что вам нужен статический контент, а управляемые модули не будут работать.

http://localhost/ <-- this one will skip managed handlers
http://localhost/default.aspx <-- this one will run them

Если я вручную установлю документ по умолчанию IIS7, то первый будет default.aspxЯ не вижу никакой разницы. Для меня это выглядит, ходит и звучит как ошибка. И это ошибка! Зачем? Потому что, когда я запрашиваю первый, это управляемый запрос, не так ли? Конечно, это. Но IIS7 рассматривает это как статический запрос. Так? Это ошибка. Этот запрос должен рассматриваться как управляемый.

Как убедить IIS7 запустить управляемые обработчики для URL-запросов без имен файлов внутри?

Помогите с мышлением

Позвольте мне немного помочь вам с размышлениями: если бы я изменил порядок system.webServer/handlersЯ уверен, что мог решить это. До последнего StaticFile обработчик, который указывает на StaticFileModule, DefaultDocumentModule а также DirectoryBrowsingModule Я должен работать встроенный обработчик asp.net на запросы каталога. Или напишите мой собственный обработчик, который добавит документ по умолчанию к любому запросу каталога. Я уверен, что один из них должен решить это. Но как мне настроить / разработать его?

2 ответа

Решение

Это реальное решение, которое решает эту ошибку управляемого запроса
Ответ на Stackoverflow.com

Это не ошибка - это то, как работает предварительное условие управляемого обработчика. Это делает так, что модуль будет обрабатываться только страницами, для которых определен управляемый обработчик.

Вы можете снять предварительное условие, и тогда оно будет анализировать все, но тогда вы потеряете прирост производительности, если не анализировать статический контент.

Лучше всего, вероятно, хранить весь статический контент в отдельном каталоге и использовать web.config для удаления модуля.

Другие вопросы по тегам