Пользовательские ошибки, не работающие с IISExpress

#iis-7.5 #iis-express #custom-error-pages

#iis-7.5 #iis-express #пользовательские страницы ошибок

Вопрос:

У меня есть asp.net приложение mvc и я пытаюсь получить пользовательские ошибки, работающие с IISExpress.

Работает в Casini нормально:

 <customErrors mode="On" defaultRedirect="/error">
  <error statusCode="404" redirect="/error/notfound"/>
</customErrors>
  

Когда я ранее развертывал сайты mvc в IIS (7.5), все, что мне нужно было сделать, чтобы мои пользовательские ошибки работали, это установить:

 <httpErrors errorMode="Detailed"/>
  

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

 <httpErrors errorMode="Detailed" defaultResponseMode="Redirect">
  <clear/>
  <error statusCode="404" path="/error/notfound"/>
</httpErrors>
  

Есть идеи?

Спасибо, Бен

Ответ №1:

Частично это было вызвано моим непониманием того, как на самом деле вызываются пользовательские ошибки, а также тем фактом, что (ИМХО) обработка ошибок в asp.net mvc немного испорчен.

Первая проблема заключалась в том, что в ряде моих методов action я проверял наличие объекта, например, записи в блоге, и возвращал HttpNotFoundResult, если запись в блоге была нулевой. Я предполагал, что это приведет к отображению пользовательской страницы ошибок, которую я настроил для ошибок 404.

Однако это не тот случай. Возврат HttpNotFoundResult просто устанавливает код состояния ответа на 404. Остальное затем обрабатывается IIS, отображая страницу ошибки IIS 404 или вашим браузером, если у него есть собственная страница пользовательских ошибок.

Одним из решений здесь является возврат HttpException, который будет использовать ваши пользовательские страницы ошибок, поскольку запрос обрабатывается asp.net .

Вместо этого я решил создать новый ActionResult, который позволил мне указать представление вместе с кодом состояния http. Я предпочел это исключениям.

Следующая проблема заключалась в том, что по умолчанию в новом проекте MVC определен жадный маршрут. Если вы сделаете запрос к /foo/bar MvcHandler по умолчанию, он будет искать вызываемый контроллер Foo . Когда он не сможет найти это, он вернет 404.

Я удалил маршрут по умолчанию, и у меня не было жадных маршрутов. Это означало, что URL-адреса, не соответствующие ни одному из моих маршрутов, не будут обрабатываться asp.net и просто вернулись бы к IIS.

Решение здесь состояло в том, чтобы создать маршрут с шаблоном в нижней части моей конфигурации маршрутизации, чтобы соответствовать всем другим запросам и перенаправлять их пользовательскому действию PageNotFound, которое устанавливает код состояния равным 404 и отображает мое пользовательское представление.

На некоторые вещи стоит обратить внимание.

  1. Вам нужно будет настроить, httpErrors errorMode="Detailed" чтобы ваши пользовательские страницы ошибок отображались в IIS / IISExpress. Остальное, однако, можно оставить в покое.
  2. Установка defaultRedirect пути в customErrors разделе не влияет на 500 ошибок. Это потому, что global HandleErrorAttribute обрабатывает все 500 ошибок и просто ищет представление с именем «Ошибка» для отображения. Это означает, что если ваша пользовательская страница ошибок на самом деле является действием контроллера, она не будет вызвана. Вышесказанное верно, даже если вы явно укажете страницу ошибок 500.
  3. Однако вы все равно должны сохранить путь defaultRedirect, поскольку он будет использоваться для других кодов состояния, если они не указаны явно.

Комментарии:

1. httpErrors ErrorMode=»Detailed» был недостающей частью для меня, спасибо

Ответ №2:

Если вы используете iisexpress, вы можете просто закомментировать весь раздел httpErrors < !— —> в applicationhost.config и заменить его следующим:

 <httpErrors errorMode="Custom">
    <error responseMode="Redirect" statusCode="404" path="../missing/index.php" />
</httpErrors>
  

path — это URL-адрес, ведущий на страницу, специфичную для вашего пользовательского сайта

Комментарии:

1. вам не следует этого делать, вы потеряете код ответа 404

2. Тема «Пользовательские ошибки, не работающие с IISExpress», так что перенаправление переходит на страницу отсутствия конкретного сайта вместо обычной страницы ошибок IIS 404.

3. наилучшей практикой является создание пользовательской страницы ошибок с сохранением соответствующего кода ошибки

4. @SouhaiebBesbes Не могли бы вы уточнить, что вы подразумеваете под «потерей кода ответа 404»? Вы имеете в виду, что вы не вернете его в клиентский браузер или что-то еще? Если вы имеете в виду, что не вернете его в клиентский браузер, можете ли вы объяснить, почему вы хотели бы вернуть 404 клиенту?

5. Вы могли бы просто повторно установить код ответа в коде вашей пользовательской страницы 404.