Пользовательская страница 404 с элементом <httpErrors>не работает в IIS 7

Question

Я тестирую сайт IIS 7.5 с управляемым конвейерным режимом = 'Integrated'

Мой сайт предназначен для мобильных устройств и использует правильно сформированные URL-адреса для передачи параметров с минимальным набором текста. Например, «mysite.com/bob1234» в данном случае «bob1234» фактически является параметром.

В Application.BeginRequest я обрабатываю Request.Url.AbsolutePath, используя регулярное выражение, чтобы определить, правильно ли сформирован URL.

Я хотел добавить страницу Custom 404, если пользователь неправильно набирает URL, т.е. mysite.com/boob1234.

<system.web>
    <customErrors mode="RemoteOnly" defaultRedirect="~/MobileError.aspx">
      <error statusCode="404" redirect="404.htm"/>
    </customErrors>
</system.web>

И хотя это ловит ошибки, когда расширение равно «.aspx», оно не ловит 404 (s), когда не сопоставлен ни один обработчик, например, «/mysite.com/boob1234'.

».

Я следовал инструкциям и также добавил элемент в мой system.webserver

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />        
    <httpErrors defaultResponseMode="Redirect" errorMode="DetailedLocalOnly">
      <remove statusCode="404" subStatusCode="-1"/>
      <error statusCode="404" prefixLanguageFilePath="" 
              path="/mobile/MobileError.aspx" responseMode="ExecuteURL"/>
    </httpErrors>        
</system.webServer>

Но никакая итерация этого, похоже, не работает. Когда я раскомментирую блок, я получаю ошибку 500. И нет, похоже, с моим кодом проблем нет. Я получаю ошибку 500, даже когда просто пересылаю простую страницу HTML.

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

Я получаю ожидаемое: 404, брошенных IIS Web Core.

Затем, через несколько шагов, запускается CustomerErrorModule, но он завершается с ошибкой 500. Подробное сообщение

ConfigExceptionInfo: \? \ C: ..... \ MyApp \ web.config (89) : Этот раздел конфигурации не может быть используется на этом пути. Это происходит когда раздел заблокирован у родителя уровень. Блокировка либо по умолчанию (overrideModeDefault = "Deny") или установите явно с помощью тега местоположения с overrideMode = "Запретить" или наследие AllowOverride = "ложь".

Я попытался пройти по стеку .config и не нашел ссылок на overrideMode = "Deny"

Любая помощь будет потрясающей. Полностью застрял сейчас.

спасибо: Дилан

Answer 1

Вы пытались разблокировать раздел конфигурации в applicationhost.config?

<location path="example.net" overrideMode="Allow">
    <system.webServer>
        <httpErrors>
        </httpErrors>
    </system.webServer>
</location>

Ссылка: http://learn.iis.net/page.aspx/124/introduction-to-applicationhostconfig/#Locking

Answer 2

Это связано с жизненным циклом запроса в IIS. В вашем случае, когда обработчик не сопоставлен, 404 распознается еще до того, как ASP ASP будут введены в игру. Для элементов, которые явно не определены в IIS как требующие Asp.Net, ошибка IIS 404 сработает и проигнорирует любые директивы в Asp.Net. Даже если подстановочный знак применяется ко всем расширениям, этот подстановочный знак вызывается только в том случае, если IIS не обнаруживает сначала 404. Это включает в себя каталоги и все расширения файлов, явно не обработанные .Net. Поэтому, если вы попытаетесь перейти на http://mydomain.com/images/someimage.gif, а этот файл не существует, вы не получите обработчик ошибок .Net 404. Если вы измените значение .gif на .aspx, обработчик впоследствии сработает. Единственный метод, который я видел, который адекватно реагирует на это, - это изменить все ваши 404 обработчика в IIS для перенаправления в файл URL на вашем локальном сайте. Он передаст строку запроса aspxerror, но если вы добавите? Error = в своем объявлении URL, вы сможете добавить конкретную информацию.

Еще одна вещь, которую я попробовал, хотя я не уверен, что я попробовал это правильно, это переназначение сопоставления для файла в IIS. Мы определили, что Asp.Net должен обрабатывать все запросы для .gif в одной точке. У меня была проблема с тем, что изображение не вышло, вышел текст в кодировке Base64 (я думаю?). Находясь в крайнем сроке, я не преследовал это, поскольку более простым решением было использование пользовательских отображений ошибок IIS.

Answer 3

Просто удар в темноте, попробуйте добавить этот атрибут к элементу httpErrors:

existingResponse="PassThrough"

Например:

<httpErrors existingResponse="PassThrough" 
        defaultResponseMode="Redirect" 
        errorMode="DetailedLocalOnly">