В 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 для запросов к каталогу. Или напишите свой собственный обработчик, который будет добавлять документ по умолчанию к любому запросу каталога. Я почти уверен, что один из них должен решить эту проблему. Но как мне его настроить / разработать?
Это фактическое решение, которое устраняет эту ошибку управляемого запроса.
Ответ на Stackoverflow.com
Это не ошибка - так работает предварительное условие управляемого обработчика. Это сделано так, что модуль будет обрабатываться только страницами, для которых определен управляемый обработчик.
Вы можете отключить предварительное условие, и тогда оно все проанализирует, но тогда вы потеряете прирост производительности, если не проанализируете статический контент.
Лучше всего, вероятно, разместить весь статический контент в отдельном каталоге и использовать web.config для удаления модуля.