Iis о специальных сообщениях об ошибках

Содержание

Обработка ошибок HTTP

В дополнение к универсальной странице ошибки (которую мы рассмотрели в предыдущей статье) можно сконфигурировать страницы ошибок, которые будут применяться для специфичных кодов состояния HTTP, таких как 404 (возвращается, когда не удается найти целевой URL). В этой статье мы не собираемся вдаваться в подробности кодов состояния HTTP. Полный их список доступен по адресу Список кодов состояния HTTP.

Ответственность за выдачу страниц ошибок делится между ASP.NET и IIS на основе вида запрашиваемого URL. Таким образом, например, если пользователь запрашивает файл веб-формы aspx, такой как «/DoesNotExist.aspx», отвечать за генерацию ошибок будет среда ASP.NET, т.к. сервер IIS передает все запросы к веб-формам в ASP.NET Framework.

Если пользователь запрашивает URL, который не обслуживается ASP.NET, наподобие «/DoesNotExit.html», генерировать страницу ошибки будет сервер IIS. Обычно мы стремимся обращаться с ошибками в согласованной манере, так что это разделение ответственности просто означает необходимость применения желаемой политики в двух местах внутри файла Web.config. Мы хотим подчеркнуть отличающиеся ответственности, поэтому создадим отдельные страницы ошибок, которые позволят понять, когда ошибка поступает из IIS, а когда из ASP.NET.

Работа с кодами состояния HTTP, поступающими из ASP.NET

Сначала мы рассмотрим поддержку кодов состояния HTTP в ASP.NET. Для этого мы создали новый файл по имени NotFoundASP.html с содержимым, приведенным в примере ниже:

Этот файл содержит сообщение, отображаемое пользователю, и ссылку на корневой URL приложения. В данном примере мы перенаправляем пользователя на статический URL, ассоциированный с приложением. Файл NotFoundASP.html регистрируется в качестве обработчика для ошибок 404 внутри Web.config, как показано в примере ниже:

В элементе error, помещенном внутрь добавленного ранее элемента customErrors определены атрибуты, которые кратко описаны в таблице ниже:

Атрибуты, определенные в элементе customErrors/error

Код состояния HTTP, к которому относится определение

Указатель URL, который будет использоваться, когда возникает ошибка, представленная атрибутом statusCode

Можно определять несколько элементов error, по одному для каждого кода состояния, который необходимо поддерживать. В примере ниже было указано, что файл NotFoundASP.html будет использоваться в ситуации, когда клиенту должен быть возвращен код состояния 404.

Обратите внимание на формулировку: код состояния должен быть возвращен клиенту. Определяя специальные обработчики ошибок, мы предотвращаем отправку в браузер кодов состояния HTTP. Взамен браузер получает перенаправление на страницу ошибки, которое возвращает код 200, указывающий на успешность запроса.

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

Чтобы увидеть специальную страницу ошибки, необходимо запросить URL для файла с расширением, которое обслуживается ASP.NET, таким как aspx или ashx. На рисунке ниже показано сообщение об ошибке, полученное за счет запрашивания URL вида «/DoesNotExist.aspx»:

Отметим, что URL страницы с ошибкой содержит описанный в предыдущей статье параметр aspxerrorpath строки запроса.

Работа с кодами состояния HTTP, поступающими из IIS

Среда ASP.NET генерирует страницы ошибок для запросов, которые относятся к обслуживаемым ею типам файлов, а сервер IIS заботится обо всех остальных. Чтобы продемонстрировать это, мы добавили в проект примера новый файл по имени NotFoundIIS.html с применением шаблона элемента HTML Page. Содержимое этого файла представлено в примере ниже:

В сущности это тот же самый контент, который использовался в примере с ASP.NET, но с текстом, скорректированным для отражения того, что страница ошибки сгенерирована сервером IIS. Специальные страницы ошибок IIS тоже регистрируются в файле Web.config, однако в другом разделе, как показано в примере ниже:

Специальная страница ошибки устанавливается с помощью элемента httpErrors, который находится в разделе system.webServer файла Web.config. В элементе httpErrors определены атрибуты, описанные в таблице ниже:

Имя Описание
statusCode
Атрибуты, определенные в элементе system.webServer/httpErrors

Указывает путь к универсальной странице ошибки, но вы не сможете установить этот атрибут до тех пор, пока явно не разблокируете этот раздел конфигурации с помощью диспетчера IIS. Как следствие, вы не должны полагаться на этот атрибут

Указывает, как контент страницы ошибки возвращается браузеру. Значение Redirect приводит к отправке HTTP-перенаправления на страницу ошибки, значение ExecuteUPL предусматривает генерацию динамического ответа (такого как получаемый из веб-формы), а значение File обеспечивает загрузку страницы ошибки из файла. (Значение File применяется, если нужно использовать файл, не являющийся частью проекта.)

Указывает, каким образом генерируются страницы ошибок. Значение Custom приводит к генерации страниц ошибок с применением значения defaultPath (если вы можете разблокировать его) или отдельных страниц, определенных элементами error (которые рассматриваются ниже).

Значение Detailed предусматривает генерацию сообщения об ошибке, которое включает подробные сведения для разработчиков, а значение DetailedLocalOnly обеспечивает генерацию специального сообщения об ошибке для удаленных запросов и детальное сообщение для локальных запросов

Указывает, каким образом IIS поступает с ошибками, генерируемыми средой ASP.NET Framework, но только в случае отключения специальных ошибок ASP.NET. Значение PassThrough приводит к передаче ошибок ASP.NET, значение Replace предусматривает генерацию в ответ ошибки IIS для замены ошибки ASP.NET, а значение Auto обеспечивает динамическое определение поведения на основе ответа ASP.NET

В примере выше для атрибута errorMode было определено значение, включающее специальные ошибки IIS. Установить универсальную страницу ошибки, как это делалось для ошибок ASP.NET, невозможно, потому что атрибут defaultPath заблокирован.

Страницы ошибок для отдельных кодов состояния задаются с помощью элемента error, в котором определены атрибуты, перечисленные в таблице ниже:

Имя Описание
defaultPath
defaultResponseMode
existingResponse
system.webServer/httpErrors/error

Указывает URL или файл, который будет использоваться для генерации страницы ошибки

Указывает способ генерации ошибки. Этот атрибут использует те же самые значения (и переопределяет их), что и атрибут defaultResponseMode элемента httpErrors

Указывает код состояния HTTP, к которому относится элемент

Используя код подсостояния, чтобы можно было дополнительно конкретизировать причину ошибки. Эти коды не являются частью HTTP, и в своих проектах мы их не применяем

В примере выше был определен элемент error для кода состояния 404, который осуществляет перенаправление браузера на /NotFoundIIS.html. Обратите внимание, что непосредственно перед элементом error находится элемент remove:

Набор элементов error поддерживается в виде коллекции, и внутри сервера IIS определен стандартный набор как часть его конфигурации. Если определить элемент error без предварительного использования remove для удаления стандартного определения, то возникнет ошибка. В элементе remove имеется атрибут statusCode, который позволяет указать, какой стандартный элемент error должен быть удален.

Чтобы увидеть специальную страницу ошибки, поступающую из IIS, необходимо запросить URL файла, имеющего расширение, которое не обслуживается ASP.NET, такое как html. На рисунке ниже показано сообщение об ошибке, полученное в результате запроса URL вида /DoesNotExist.html:

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

Создание разделяемой динамической страницы ошибки

Итак, мы показали две разных статических HTML-страницы ошибок, которые позволяют различать ошибки, поступающие из APS.NET, и ошибки, поступающие из IIS. В реальных проектах это требуется редко, и для обоих разделов файла Web.config можно применять один и тот же URL.

Создание разделяемого динамического ответа требует несколько большей работы. Мы добавили в проект новую веб-форму по имени NotFoundShared.aspx, которая будет использоваться для демонстрации подхода. Содержимое этого файла приведено ниже:

Эта веб-форма содержит элементы , предназначенные для информирования об источнике ошибки 404 и запрошенном URL. В примере ниже устанавливается контент этих элементов в файле NotFoundShared.aspx.cs:

Этот прием полагается на то, что ошибки, генерируемые ASP.NET, имеют параметр aspxerrorpath строки запроса. То есть если этот параметр присутствует, мы предполагаем, что имеем дело с ошибкой ASP.NET, и с помощью значения параметра получаем URL, который был запрошен пользователем. Если же параметра в строке запроса нет, мы предполагаем, что имеем дело с ошибкой, поступившей из IIS, и получаем запрошенный URL из свойства HttpRequest.RawURL, доступ к которому возможен через свойство Request.

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

Чтобы появилась возможность работы со свойством RawURL, необходимо модифицировать способ генерации страниц ошибок сервером IIS, как показано в примере ниже, в котором представлены изменения, внесенные в файл Web.config для установки веб-формы разделяемой страницы ошибки:

Мы обновили URL в обоих разделах файла, чтобы использовалась веб-форма NotFoundShared.aspx. Кроме того, мы изменили значение атрибута responseMode в конфигурации IIS для применения режима ExecuteURL. Это позволяет визуализировать веб-форму без перенаправления клиента и означает, что детали запроса, вызвавшего ошибку, доступны через объект HttpRequest, в том числе и свойство RawURL. Результат запрашивания /DoesNotExist.aspx и /DoesNotExist.html можно видеть на рисунке ниже:

В этом примере отображаются сведения о том, где возникла ошибка, но пользователю такие детали предоставляться не должны. Важный аспект данного подхода заключается в том, что место возникновения ошибки известно вам. Используя эту информацию, можно создать веб-форму, которая будет применяться для генерации страниц ошибок из ASP.NET и IIS.

Указание страницы ошибки, специфичной для веб-формы

Последний способ настройки стандартного поведения предусматривает указание страницы ошибки для отдельных веб-форм с помощью атрибута ErrorPage в директиве Page. Мы нечасто используем этот прием в своих проектах, но он может быть удобен в ситуации, когда имеется небольшое количество веб-форм, требующих особого внимания, например, веб-форма аутентификации.

Несмотря на это, при создании страниц ошибок мы обычно полагаемся на коды состояния HTTP. В примере ниже демонстрируется применение атрибута ErrorPage в веб-форме Default.aspx:

В этом примере мы указали, что при появлении любых необработанных исключений из веб-формы Default.aspx должен отображаться файл DefaultASPXError.html. Теперь добавим в проект файл DefaultASPXError.html с использованием шаблона элемента HTML Page. Содержимое этого файла аналогично приведенным ранее страницам ошибок.

Чтобы этот прием работал, атрибут mode элемента customErrors должен быть установлен в On. Если этого не сделать, будет применяться стандартная страница ошибки для кода состояния http, равного 500.

Как отключить дружественные сообщения об ошибках в IIS Express, запущенные в Chrome?

Я переключаюсь с Visual Studio 2013 Development Environment на IIS Express. Моим браузером является Chrome.

Раньше я использовал стандартную страницу ошибок ASP.net в DE, но теперь у меня есть дружественная страница сообщений об ошибках в IIS Express. Как показать подробные сообщения об ошибках в Chrome?

Если вам интересно, я знаю, что в моем коде есть ошибка. Я специально сделал это, чтобы увидеть, как отображение сообщений об ошибках в IIS Express

Коды состояния служб IIS

Аннотация

При обращении пользователей к серверу, на котором запущены информационные службы Интернета (Internet Information Services, IIS), по протоколу HTTP или FTP (File Transfer Protocol), сервер возвращает число, показывающее состояние выполнения запроса. Данное число называется кодом состояния и сохраняется в журнале служб IIS, а также может отображаться веб-обозревателем или клиентом FTP. Код состояния показывает, выполнен ли запрос, а также может сообщать о причинах сбоя при выполнении запроса.

Дополнительная информация

Местонахождение файла журнала
По умолчанию файлы журналов служб IIS находятся в папке %WIN DIR\System32 \Logfiles. Данная папка содержит отдельные подкаталоги для каждого узла WWW (World Wide Web) и FTP. По умолчанию новый файл журнала создается ежедневно. Имя данного файла формируется, исходя из текущей даты (например exГГММДД.log). HTTP

1xx — Информационные коды

Перечисленные ниже коды состояния представляют собой предварительные ответы. Перед получением окончательного ответа клиент может получить один или несколько ответов с кодами состояния 1xx.

  • 100 — Следует продолжать работу.
  • 101 — Смена протоколов.

2xx — Запрос принят

Нижеперечисленные коды показывают, что сервер успешно принял запрос клиента.

  • 200 — ОК. Запрос выполнен успешно.
  • 201 — Создан ресурс.
  • 202 — Запрос принят.
  • 203 — Неавторизованные сведения.
  • 204 — Содержимое отсутствует.
  • 205 — Сброс содержимого.
  • 206 — Частичный ответ.

3xx — Перенаправление

Данные коды показывают, что для выполнения запроса необходимо, чтобы в еб-обозреватель клиента выполнил дополнительные действия. Например, может потребоваться, чтобы веб-обозреватель запросил с сервера другую страницу или повторил запрос, используя прокси-сервер.

  • 302 — Объект перемещен.
  • 304 — Объект не изменялся.
  • 307 — Временное перенаправление.

4xx — Ошибка на стороне клиента

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

  • 400 — Неверный запрос.
  • 401 — Отсутствуют необходимые права доступа. Если возникает ошибка с кодом 401, то службы IIS возвращают расширенный код, указывающий причину ошибки. Это коды отображаются на экране веб-обозревателя, но не регистрируются в журнале служб IIS.
  • 401.1 — Вход в систему не выполнен.
  • 401.2 — Вход не выполнен из-за настройки сервера.
  • 401.3 — Доступ запрещен таблицей управления доступом (ТУД) к ресурсу.
  • 401.4 — Доступ запрещен фильтром.
  • 401.5 — Доступ запрещен приложением ISAPI/CGI.
  • 401.7 — Доступ запрещен политикой авторизации URL веб-сервера. Данный код поддерживается только службами IIS 6.0.
  • 403 — Запрет доступа. Если возникает ошибка с кодом 403, то службы IIS возвращают расширенный код, указывающий причину ошибки.
  • 403.1 — Нет доступа на выполнение.
  • 403.2 — Нет доступа на чтение.
  • 403.3 — Нет доступа на запись.
  • 403.4 — Требуется протокол SSL.
  • 403.5 — Требуется протокол SSL 128.
  • 403.6 — IP-адрес отклонен.
  • 403.7 — Требуется сертификат для клиента.
  • 403.8 — Отказ в доступе к узлу.
  • 403.9 — Подключено слишком много пользователей.
  • 403.10 — Недопусти мая конфигурация.
  • 403.11 — Необходим другой пароль.
  • 403.12 — Отказ доступа от программы сопоставления.
  • 403.13 — Клиентский сертификат отозван.
  • 403.14 — Просмотр каталога запрещен.
  • 403.15 — Достигнуто максимальное число разрешенных одновременных подключений.
  • 403.16 — Клиентский сертификат недействителен или не вызывает доверия.
  • 403.17 — Срок действия клиентского сертификата уже истек или еще не начался.
  • 403.18 — Не удается выполнить запрошенный адрес URL в текущем пуле приложения. Данный код поддерживается только с лужбами IIS 6.0.
  • 403.19 — Не возможно выполнять прило жения CGI для этого клиента в данном пуле приложений. Данный код поддерживается только службами IIS 6.0.
  • 403,20 — Вход систему с помощью служб Passport не выполнен. Данный код поддерживается только службами IIS 6.0.
  • 404 — Объект не найден.
  • 404.0 — (отсутствует) — Файл или каталог не найден.
  • 404.1 — Веб-узел не доступен по запрошенному порту.
  • 404.2 — Запрос отклонен политикой закрытия расширений веб-служб.
  • 404.3 — Запрос отклонен политикой сопоставления MIME.
  • 405 — Для доступа к странице используется недопустимый метод HTTP (недопустимый метод).
  • 406 — Веб-обозреватель клиента на поддерживает тип MIME запрошенной страницы.
  • 407 — Требуется проверка подлинности через прокси-сервер.
  • 412 — Отказ после проверки предварительного условия.
  • 413 — Размер запроса слишком велик.
  • 414 — Слишком длинный запрос URI.
  • 415 — Неподдерживаемый тип носителя.
  • 416 — Значение за пределами диапазона.
  • 417 — Ошибка при выполнении.
  • 423 — Ошибка блокировки.
  • 5xx — Ошибки сервера

    Данные к оды показывают, что сервер не может выполнить запрос, поскольку при выполнении возникла ошибка.

    • 500 — Внутренняя ошибка сервера.
    • 500.12 — Приложение в процессе перезапуска.
    • 500.13 — Сервер перегружен.
    • 500.15 — Запросы на файл Global.asa недопустимы.
    • 500.16 — Учетные данные не позволяют выполнить проверку подлинности при подключении к адресу UNC. Данный код поддерживается только службами IIS 6.0.
    • 500.18 — Не удается открыть хранилище данных авторизации URL. Данный код поддерживается только службами IIS 6.0.
    • 500.100 — Внутренняя ошибка ASP.
  • 501 — Значения, указанные в заголовке, требуют нереализованную возможность.
  • 502 — Выполняя роль шлюза или прокси, веб-сервер получил ошибочный ответ.
  • 502.1 — Превышен интервал ожидания ответа от приложения CGI.
  • 502.2 — Ошибка в приложении CGI.
  • 503 — Служба недоступна. Данный код поддерживается только службами IIS 6.0.
  • 504 — Превышен интервал ожидания ответа от шлюза.
  • 505 — Неподдерживаемая версия HTTP.
  • Основные коды состояния HTTP и их описание

    • 200 — Запрос выполнен успешно. Данный код показывает, что сервер IIS успешно обработал запрос.
    • 304 — Объект не изменялся. Клиент запросил документ, который имеется в кэше клиента и не изменялся после кэширования. Вместо загрузки документа с сервера клиент использует кэшированную копию данно го документ а.
    • 401.1 — Вход в систему не выполнен. При входе в системе произошел сбой (как правило, вследствие указания ошибочного имени пользователя или пароля).
    • 401.3 — Доступ запрещен списком управления доступом (ACL) к ресурсу. Появление данного кода свидетельствует о проблеме с разрешениями NTFS. Эта ошибка может возникать, даже если для запрашиваемого файла разрешения установлены правильно. Например, данная ошибка появляется, если для учетной записи IUSR отсутствуют права доступа к папке C:\Winnt\System32\Inetsrv. Дополнительные сведения об устранении данной ошибки см. в следующей статье базы знаний Майкрософт: 187506 (http://support.microsoft.com/kb/187506/) Разрешения NTFS и права пользователей, необходимые для работы сервера IIS 4.0
    • 403.1 — Нет доступа на выполнение. Как правило, данная ошибка возникает по следующим причинам.
    • Отсутствует право на выполнение. Например, данная ошибка может возникать при обращении к странице ASP, находящейся в папке, для которой отсутствуют разрешения на выполнение, или при запуске сценария CGI из папки, для которой установлены разрешения «Только сценарии». Чтобы добавить право выполнения, в соответствующей консоли MMC щелкните нужную папку правой кнопкой мыши, выберите пункт Свойства, перейдите на вкладку Каталог и убедитесь, что для требуемых объектов разрешения Разрешен запуск установлены должным образом.
      Используемый метод (например GET или POST) отсутствует в сопоставлении сценариев для требуемого типа файлов. Чтобы проверить, присутствует ли требуемый метод, в соответствующей консоли MMC щелкните нужную папку правой кнопкой мыши, выберите пункт Свойства, перейдите на вкладку Каталог, щелкните команду Конфигурация и убедитесь, ч то в сопоставлении сценариев для требуемого типа файлов разрешено использование соответствующего метода.
    • 403.2 — Нет доступа на чтение. Убедитесь, что в конфигурации служб IIS разрешено чтение из данной папки. Кроме того, если используется документ по умолчанию, убедитесь, что данный документ существует. Дополнительные сведения об устранении данной проблемы см. в следующей статье базы знаний Майкрософт: 247677 (http://support.microsoft.com/kb/247677/) Появление сообщения об ошибке «403.2 Запрет доступа. Нет доступа на чтение.»
    • 403.3 — Нет доступа на запись. Убедитесь, что существующие разрешения IIS и разрешения NTFS позволяют выполнять запись в нужную папку.Дополнительные сведения об устранении данной проблемы см. в следующей статье базы знаний Ма й крософт: 248072 (http://support.microsoft.com/kb/248072/) Появление сообщения об ошибке «403.3 Запрет доступа. Нет доступа на запись.»
    • 403.4 — Требуется протокол SSL. Отключите параметр Требует ся безопасный канал или используйте для доступа к данной странице протокол HTTPS, а не HTTP. Если эта ошибка появляется при обращении к веб-узлу, для которого не установлен сертификат, обратитесь к следующей статье базы знаний Майкрософт: 224389 (http://support.microsoft.com/kb/224389/) Появление сообщений об ошибках 403, 403.4, 403.5 «Запрет доступа. Требуется протокол SSL.»
    • 403.5 — Требуется протокол SSL 128. Отключите параметр Требуется 12 8 -и разрядное шифрование или используйте для просмотра данной страницы веб-обозреватель, поддерживающий 128-разрядное шифрование. Если эта ошибка появляется при обращении к веб-узлу, для которого не установлен сертификат, обратитесь к следующей статье базы знаний Майкрософт: 224389 (http://support.microsoft.com/kb/224389/) Появление сообщений об ошибках 403, 403.4, 403.5 «Запрет доступа. Требуется протокол SSL.»
    • 403.6 — IP-адрес отклонен. Конфигурация веб-сервера запрещает доступ с да нн ого IP-адреса. Дополните льные сведения об устранении данной проблемы см. в следующей статье базы знаний Майкрософт: 248043 (http://support.microsoft.com/kb/248043/) При подключении к веб-серверу появляется сообщение об ошибке: «Ошибка HTTP 403.6 — Запрет доступа: IP-адрес отклонен»
    • 403.7 — Требуется сертификат для клиента. Конфигурация веб-сервера требует наличие сертификата для выполнения проверки подлинности клиента, однако серт ификат для клиента не установлен. Дополнительные сведения см. в следующих статьях базы знаний Майкрософт. 190004 (http://support.microsoft.com/kb/190004/) Появление сообщения об ошибках 403.7 или «Не удается установить соединение с сервером» 186812 (http://support.microsoft.com/kb/186812/) PRB: Появление сообщения об ошибке «403.7 Запрет доступа. Требуется сертификат для клиента.»
    • 403.8 — Отказ в доступе к узлу. Существующие ограничения на доменное имя запрещают доступ к веб-узлу из текущего домена.Дополнительные сведения об устранении данной проблемы см. в следующей статье базы знаний Майкрософт: 248032 (http://support.microsoft.c om/kb/248032/) Появление сообщения об ошибке «403.8 Запрет доступа. Отказ в доступе к узлу.»
    • 403.9 — Подключено слишком много пользователей. Число пользователей, подключенных к веб-узлу, превысило максимально допустимое число подключений, указанное в конфигурации. Дополнительные сведения об изменении данного значения см. в следующей с тать е базы знаний Майк ро софт: 248074 (http://support.microsoft.com/kb/248074/) Ошибка HTTP 403.9 — Запрет доступа: подключено слишком много пользователей Примечание. Microsoft Windows 2000 Professional и Microsoft Windows XP Professional допускают одновременное подключение к службам IIS десяти пользователей. Это значение изменить нельзя.
    • 403.12 — Отказ доступа от программы сопоставления. Для доступа к запрошенной странице необходим сертификат клиента, однако пользователь, сопоставленный используемому клиентскому сертификату, не имеет прав доступа к данному файлу. Дополнительные сведения см. в следующей статье базы знаний Майкрософт: 248075 (http://support.microsoft.com/kb/248075/) Появление сообщения об ошибке «403.12 Запрет доступа. Отказ до с тупа от программы сопоставления.»
    • 404 — Объект не найден. Данная ошибка может возникать, если запрошенный файл был удален или перемещен. Кроме того, указанное сообщение об ошибке появляется, если после установки средства URLScan был ограничен доступ к файлам с запрошенным расширением. В этом случае в файле журнала для данного запроса будет добавлена строка «Rejected by URLScan».
    • 500 — Внутренняя ошибка сервера. Данное сообщение об ошибке может появляться вследствие различных причин. Дополнительные сведения о причинах подобных ошибок могут помещаться в журнал событий. Кроме того, для получения полного описания ошибки можно отключить вывод подробных сообщений об ошибках HTTP. Дополнительные сведения об отключении вывода подробных сообщений об ошибках HTTP см. в следующей статье базы знаний Майкрософт: 294 807 (http://support.microsoft.com/kb/294807/) Отключение параметра «Выводить подробные сообщения об ошибках http» в обозревателях Internet Explorer 5.x и 6.x на стороне сервера
    • 500.12 — Приложение в процессе перезапуска. Данное сообщение появляется при попытке загрузить страницу ASP в то время, когда сервер IIS перезапускает приложение. После обновления страницы данное сообщение должно исчезнуть. Если после обновления страницы указа нно е сообщение остается, то это может быть вызвано работой антивирусной программы, которая проверяет файл Global.asa. Дополнительные сведения см. в следующей статье базы знаний Майкрософт: 248013 (http://support.microsoft.com/kb/248013/) Сообщение «Ошибка HTTP 500-12 Перезапуск приложения» при подключении к Microsoft Internet Information Services 5. 0
    • 500-100.ASP — Внутренняя ошибка ASP. Данное сообщение об ошибке появляется при загрузке страницы ASP, содержащей ошибки. Чтобы получить более полную информацию о данной ошибке, отключите вывод подробных сообщений об ошибках HTTP. По умолчанию данная ошибка может появляться только на веб-узле по умолчанию.Дополнительные сведения о том, как увидеть данную ошибку на веб-узлах, не являющихся узлами по умолчанию, см. в следующей статье базы знаний Майкрософт: 261200 (http://support.microsoft .com/kb/261200/) Вместо сообщения об ошибке из файла 500-100.asp отображается сообщение об ошибке HTTP с кодом 500
    • 502 — Неправильный шлюз. Данное сообщение об ошибке появляется при запуске сценария CGI, не возвращающего соответствующий набор заголовков HTTP.

    1xx — Положительный предварительный ответ

    Данный код состояния говорит о том, что выполнение действия началось успешно, но перед переходом к новой команде клиент должен дождаться следующего ответа.

    • 110 Значение маркера повторного запуска.
    • 120 Служба будет готова через ххх минут.
    • 125 Соединение для передачи данных уже уст ановл ено; передача данных начата.
    • 150 Состояние файла проверено. Сервер готов к установке соединения для передачи данных.

    2xx — Оповещение о выполнении команды

    Действие завершилось успешно. Клиент может выполнять следующую команду.

    • 200 Команда выполнена успешно.
    • 202 Команда не реализована. На данном узле к о манда не тре буется.
    • 211 Состояние системы или справка по системе.
    • 212 Состояние каталога.
    • 213 Состояние файла.
    • 214 Справочное сообщение.
    • 215 ИМЯ тип системы, где ИМЯ — официальное имя системы в соответствии с документом о присвое нии номеров.
    • 220 Система готова обслуживать нового пользователя.
    • 221 Служба разрывает управляющее соединение. Если необходимо, будет произведен выход из системы.
    • 225 Соединение для передачи данных установлено; передача не выполняется.
    • 226 Соединение для передачи данных разрывается. Требуемое действие выполнено (например пере да ча или прекращение переда чи файла).
    • 227 Выполняется вход в пассивный режим (h1,h2,h3,h4,p1,p2).
    • 230 Пользователь вошел в систему. Производится обработка.
    • 250 Требуемое действие завершено успешно.
    • 257 Создана папка «ПУТЬ».

    3xx — Положительные промежуточные ответы

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

    • 331 Имя пользователя получено. Необходимо ввести пароль.
    • 332 Необходима учетная запись для входа в систему.
    • 350 Для выполнения запрашиваемого действия требуются дополнительные данные.

    4xx — Промежуто ч ные отрицательные ответы

    При выполнении команды возникла временная ошибка. Если клиент повторит команду, она может выполниться успешно.

    • 421 Служба недоступна. Управляющее соединение разрывается. Данное сообщение может отправляться в ответ на какую-либо команду, если служба должна завершить работу.
    • 425 Не удается установить соединение для передачи данных.
    • 426 Соединение разорвано; передача прекращена.
    • 450 Требуемое действие не выполнено. Файл недоступен (например, файл может быть занят).
    • 451 Выполнение требуемого действия прервано: при выполнении возникла ошибка.
    • 452 Требуемое действие не выполнено. Системе не хватает места на диске.

    5xx — Окончательные отрицательные ответы

    При выполнении команды возникла ошибка. Данная ошибка носит постоянный характер. Если клиент повто рит команду, при ее выполнении возникнет такая же ошибка.

    • 500 Синтаксическая ошибка. Команда не распознана. Одной из причин возникновения этой ошибки является использование слишком длинных команд.
    • 501 Синтаксическая ошибка в аргументах или параметрах.
    • 502 Команда не реализована.
    • 503 Ошибочная последовательность команд.
    • 504 Для данного параметра команда не реализована.
    • 530 Не выполнен вход в систему.
    • 532 Необходима учетная запись для сохранения файлов.
    • 550 Требуемое действие не вы п олнено. Файл недоступен (например, файл не найден или нет доступа к файлу).
    • 551 Выпо лнение требуемого действия прервано. Неизвестный тип страницы.
    • 552 Выполнение требуемого действия прервано. Превышен максимально допустимый объем места на диске (в текущей папке или в наборе данных).
    • 553 Требуемое действие не выполнено. Недопустимое имя файла.

    Основные коды состояния FTP и их описание

    • 150 — Протокол FTP использует два порта: порт 21 для передачи команд и порт 20 для передачи данных. Код состояния 150 показывает, что сервер собирается установить новое соединение на порту 20 для передачи данных.
    • 226 — Команда устанавливает подключение к порту 20, чтобы выполнить какие-либо действия (например передать файл). Данное действие было завершено успешно. Соединени е разорвано.
    • 230 — Сообщение с этим кодом появляется после отправки клиентом правильного пароля. Данный код состояния показывает, что пользователь вошел в систему.
    • 331 — Сообщение с этим кодом появляется после отправки клиентом имени пользователя. Это сообщение появляется независимо от того, присутствует ли в системе указанное имя пользователя.
    • 426 — Команда устанавливает подключение к порту 20, чтобы выполнить какие-либо действия, однако выполнение действия было отменено и соединение было разорвано.
    • 530 — Данный код состояния показывает, что пользователь не может войти в систему, поскольку введена ошибочная комбинация имени пользователя и пароля. Если для входа в систему используется учетная запись пользователя, то данное сообщение может появляться, если имя пользо вателя или пароль введены н еправильно или если в систем у могут входить только анонимные пользователи. Если для входа в систему используется анонимная учетная запись, то данное сообщение может появляться, если сервер IIS не поддерживает вход анонимных пользователей.
    • 550 — Команда не выполнена, поскольку требуемый файл недоступен. Данное сообщение может появляться при попытке получить отсутствующий файл с помощью команды GET, при использовании команды PUT для сохранения файла в папке, для которой отсутствует право записи, а также в некоторых других случаях.

    показать сообщение об ошибке php на IIS 7

    Я использую IIS как веб-сервер на моей машине разработки для PHP-разработки. Или, по крайней мере, я пытаюсь.

    Когда в скрипте PHP есть синтаксическая ошибка, и я открываю этот файл в своем веб-браузере, я просто получаю 503 «внутреннюю ошибку сервера» и страницу ошибок IIS по умолчанию для этой ошибки. Некоторые браузеры вообще не открывают этот файл, возможно, из-за заголовка ответа HTTP 503.

    Я бы хотел, чтобы IIS действовал в этом случае точно так же, как веб-сервер apache: так или иначе отображайте файл PHP с ошибкой, чтобы сообщение об ошибке было распечатано.

    Подробное сообщение об ошибке 500, ASP + IIS 7.5

    IIS 7.5, 2008rc2, классический asp, 500 ошибка msg:

    страница не может быть отображена из-за внутренней ошибки сервера.

    Мне нужно знать, как настроить IIS для получения более подробной ошибки.
    Я попытался установить значение true для всех параметров отладки в конфигурации ASP.
    Но это не сработало. Кто-нибудь может мне помочь?

    12 ответов

    Я пришел к той же проблеме и исправил так же, как Алекс K.

    поэтому, если» отправить ошибки в браузер » не работает, установите также это:

    Страницы Ошибок — > 500 — > Изменить Настройки Функций — > «Подробные Ошибки»

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

    Если вы находитесь на удаленном сервере, вы можете настроить свой веб.конфигурационный файл так:

    дважды щелкните » ASP «на главном экране сайта в IIS admin, разверните» свойства отладки», включите» отправить ошибки в браузер «и нажмите»Применить».

    В разделе » страницы ошибок «на главном экране выберите» 500″, затем» изменить настройки функций «и выберите»подробные ошибки».

    обратите внимание, что те же шаги применяются для IIS 8.0 (Windows Server 2012).

    после Вацлава и Алекс ответ, мне все равно пришлось отключить «показывать дружественные сообщения об ошибках HTTP» в IE

    на web.config под

    заменить (или добавить) строку

    это потому, что по умолчанию IIS7 перехватывает коды состояния HTTP, такие как 4xx и 5xx, генерируемые приложениями далее по конвейеру.

    далее включить «выводить ошибки в браузер «в разделе» ASP «и в разделе»Страницы Ошибок / Изменить Настройки Функций«, выбираем «вся ошибки.»

    также запись в папке веб-сайта в группу iis_iusrs встроенные группы.

    попробуйте установить значение атрибута httpErrors «existingResponse»в » PassThrough». Мой был установлен на «заменить», что заставляло YSOD не отображаться.

    TLDR: сначала определите, где в конвейере вы получаете ошибку (прокрутите поиск скриншотов чего-то, что напоминает вашу ошибку), внесите изменения, чтобы получить что-то новое, повторите.

    сначала определите, какое сообщение об ошибке вы на самом деле видите.

    Если вы видите файл, расположенный здесь.

    . который обычно выглядит как это:

    . тогда вы знаете, что видите настроенную страницу ошибок в * * IIS * * и вам не нужно изменять настройки customErrors, настройки ASP error detail или настройки браузера «показать дружественные ошибки http».

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

    » Да, я вижу вышеописанное ошибка. «

    в этом случае, вы видите настройку httpErrors> или в диспетчере IIS это Страницы Ошибка — > «Редактировать Параметры Объекта». По умолчанию для этого используется errorMode=DetailedLocalOnly в уровень узла сервера (в отличие от уровня сайта) это означает, что, хотя вы увидите эту настроенную страницу ошибок на удаленном компьютере, вы сможете локально войти на сервер и увидеть полную ошибку, которая должна выглядеть примерно так это:

    У вас должно быть все, что вам нужно в этот момент, чтобы исправить текущую ошибку.

    «но я не вижу подробной ошибки даже при просмотре на сервере»

    Это оставляет пару возможностей.

    1. браузер вы используете на сервере настроен на использование прокси-сервера в его настройках подключения он не рассматривается как «локальный».
    2. вы на самом деле не сидя в сайт, на который вы просматриваете-это обычно происходит, когда задействован балансировщик нагрузки. Выполните проверку ping, чтобы узнать, дает ли dns вам IP-адрес на сервере или где-то еще.
    3. Вы сайт httpErrors настройки установлены только для» Custom». Измените его на «DetailedLocalOnly». Однако при возникновении ошибки конфигурации это может не сработать, так как httpErrors уровня сайта также является элементом конфигурации. В этом случае перейдите к #4
    4. по умолчанию для httpErrors для всех сайтов установлено значение «Custom». В этом случае вам нужно нажать на серверный узел верхнего уровня в диспетчере IIS (а не на конкретный сайт) и изменить httpErrors настройки там для DetailedLocalOnly. Если это внутренний сервер, и вы не беспокоитесь о разглашении конфиденциальной информации, вы также можете установить его на «подробный», который позволит вам увидеть ошибку от клиентов, отличных от сервера.

    «вход в сервер не является вариантом для меня»

    измените свой сайт httpErrors «подробно», чтобы вы могли видеть его удаленно. Но если это не работает, ваша ошибка уже может быть ошибкой конфигурации, см. #3 непосредственно выше. Таким образом, вы можете застрять с #4, и вам понадобится кто-то из вашей команды серверов.

    » Я не вижу страницу ошибки, описанную выше. Я вижу что-то другое»

    если вы видите этот.

    . и вы ожидаете увидеть нечто подобное.

    . затем вам нужно изменить «отправить ошибки в браузер» на true в диспетчере IIS в разделе Site IIS ASP Debugging Properties

    если вы видите эту.

    . вам нужно отключите дружественные ошибки в вашем браузере или используйте WebView fiddler, чтобы посмотреть на актуальный ответ vs, что ваш браузер выбирает, чтобы показать вам.

    Если вы видите эту.

    . тогда пользовательские ошибки работают, но у вас нет пользовательской страницы ошибок (конечно, на данный момент речь шла о .net, а не о классическом asp). Вам нужно изменить тег customErrors в вашем интернете.config to RemoteOnly для просмотра на сервере, или Выключено для удаленного просмотра.

    Если вы видите что-то, что стилизовано как ваш сайт, то пользовательские ошибки, вероятно, On или RemoteOnly, и он отображает пользовательскую страницу (представления->общий — >ошибка.например, cshtml в MVC). Тем не менее, маловероятно, но возможно, что кто-то изменил страницы в IIS для httpErrors, поэтому см. Первый раздел об этом.

    одна вещь, о которой никто не упоминал, — это очень быстрое и временное исправление, вы можете просмотреть ошибку на localhost этого веб-сервера.

    вы также можете проверить, что если вы изменили свою основную папку веб-сайта ( c:\inetpub\wwwroot ) в другую папку, вы должны дать разрешение на чтение группа IIS_IUSRS в новой папке.

    Fot люди, которые пробовали все и просто не могут получить детали ошибки, чтобы показать, как я, это хорошая идея, чтобы проверить различные уровни конфигурации. У меня есть файл конфигурации на уровне сайта и на уровне приложения (внутри сайта) проверить обоих. Кроме того, как оказалось, у меня были подробные ошибки, отключенные на самом высоком узле в IIS (прямо под начальной страницей, у него есть имя, которое совпадает с именем компьютера webservers). Проверьте страницы ошибок там.

    запустить cmd от имени администратора, перейдите в папку system32\inetsrv и выполнить:

    теперь я вижу подробные ошибки asp .

    Если вы запустите браузер на сервере и протестируете свой url-адрес проекта с локальным ip-адресом, вы получили все ошибки этого проекта без общей страницы ошибок(например, страница 500 ошибок).

    Семь (!) ошибок в IIS

    Xakep #246. Учиться, учиться, учиться!

    Найдено 7! уязвимостей в IIS 4.0-5.1, четыре из которых могут приводить к выполнению произвольного кода, две к отказу в обслуживании и одна к межсайтовому скриптингу.

    1. Переполнение буфера в механизме кодирования ASP страниц в IIS 4.0 и 5.0. Уязвимость позволяет удаленному нападающему переполнять буфер в системе с возможностью выполнения произвольного кода с правами IWAM_COMPUTERNAME. Еще одна похожая уязвимость найдена Microsoft в механизме передачи данных ASP. Последствия такие же, но уязвим также и IIS 5.1 (В первом случае только IIS 4.0-5.0).

    2. Переполнение буфера при обработке HTTP заголовков в IIS 4.0, 5.0, 5.1. В принципе, в IIS присутствует проверка правильности полей НTTP заголовков перед передачей их IIS. Однако, можно обмануть этот механизм, убеждая IIS в правильности переданных заголовков. Уязвимость позволяет удаленному нападающему создавать URL c HTTP заголовком, значение полей которого могут вызвать переполнение буфера при его обработке. Уязвимость может приводить к выполнению произвольного кода с правами IWAM_COMPUTERNAME.

    3. Из-за неправильной обработкой SSI (server-side includes) можно переполнить буфер. В некоторых случаях запрос web-страницы требует выполнение файла, включенного в ASP сценарий. До обработки включающегося запроса IIS выполняет проверку имени файла, заданного пользователем для того, чтобы гарантировать, что допустимо имя файла и что его размер соответствует статическому буферу. Однако, в некоторых случаях, можно
    передать серверу чрезвычайно длинное имя файла, который обойдет такую проверку, приводя к переполнению буфера. Уязвимость может приводить к выполнению произвольного кода с правами IWAM_COMPUTERNAME.

    4. Переполнение буфера найдено в HTR ISAPI в IIS 4.0 и 5.0.
    Серия неправильных HTR запросов может привести к зависанию службы IIS и, возможно, к выполнению произвольного кода. Уязвимость может приводить к выполнению произвольного кода с правами IWAM_COMPUTERNAME (нападающий при этом должен знать точное местоположение буфера в памяти).

    5. Нарушение доступа в обработке ошибки:
    отказ от обслуживания найден в процедуре,
    которая в IIS обрабатывает ошибки ISAPI фильтров. По крайней мере один ISAPI фильтр (который поставляется с FrontPage Server Extensions и ASP.NET) и возможно другие,
    выдает ошибку при получении запроса, которая превышает максимальную длину, установленную фильтром. Уязвимость может приводить только к отказу в обслуживании. ASP.NET не установлен по умолчанию и FPSE может быть деинсталлирован.

    6. DoS при обработке запросов состояния FTP сервера. Если атакующий сможет установить FTP-сеанс с сервером и инициировать запрос состояния, который вызвал бы ошибку, то дефект FTP-кода помешает ему правильно сформировать сообщение об ошибке. После этого другой код попытается использовать неинициализированные данные, результатом чего станет нарушение прав доступа. В результате аварийно завершится работа не только FTP службы, но и Web службы.

    7. Найдено три возможности создания перекрестного сценария (Cross-Site Scripting): первая — в странице с результатами, которая возвращена при поиске IIS Help Files, другая — в странице HTTP ошибки; и третья — в странице, которая сообщает, что требуемый URL был переадресован. Уязвимость позволяет создавать
    специальную ссылку, содержащую код, который будет выполнен в контексте уязвимого сайта.

    Диагностика и исправление ошибок в приложениях IIS

    Кен Спенсер

    Имя Описание
    path
    responseMode
    statusCode
    subsStatusCode
    Мысленно возвращаясь к первым дням ажиотажа вокруг Web, вспоминаю неподвижные Web-страницы и картинки в окне браузера. В те времена Web-сервер мог лишь обрабатывать запросы на передачу файлов по протоколу HTTP. Возможности современных Web-серверов гораздо шире, но и хлопот с их обслуживанием у администраторов стало куда больше. Теперь Web-серверы превратились в полноценные серверы приложений: на них устанавливают мощные программные пакеты, их связывают с базами данных и множеством других систем. Web-серверы больше не занимаются только лишь передачей файлов, им приходится осуществлять самые разные технологические процедуры и управлять ими, а также руководить комплексным обменом информацией между пользователями и сервером. Все эти процессы настолько сложны, что вероятность отказа современного Web-сервера достаточно высока.

    Режим ядра и фоновый режим

    Основное преимущество Microsoft Internet Information Server (IIS) 4.0 заключается в его способности выполнять приложения как внутри собственного процесса, так и вне его. По умолчанию, IIS запускает каждое приложение в рамках адресного пространства своего собственного процесса (inetinfo.exe). Чтобы оценить интенсивность работы приложений в этом режиме, можно запустить утилиту Task Manager или Performance Monitor и посмотреть, как процесс inetinfo.exe использует ресурсы процессора.

    Выполнение приложений в адресном пространстве процесса IIS обеспечивает им максимально быстрый доступ к ресурсам сервера и повышает эффективность их работы. В таком режиме, например, работает высокопроизводительное приложение FMStocks, разработанное для Microsoft компанией Vertigo Software. В то же время запуск всех программ в адресном пространстве IIS 4.0 имеет свои недостатки, поскольку в этом случае они могут воздействовать друг на друга. Так, отказ одного из них вполне может привести к «обвалу» остальных. Правда, если сбой прикладного компонента произошел вследствие логической ошибки, он обычно не оказывает влияния на работу IIS и других приложений. Однако, когда такой сбой происходит в результате попытки приложения получить доступ к памяти вне адресного пространства процесса, он может привести к отказу IIS и остальных приложений.

    ЭКРАН 1. Страница свойств тестового приложения.

    При возникновении проблемы в работе IIS прежде всего нужно локализовать ее источник. Поэтому если приложение периодически «падает» и останавливает работу Web-сервера, его следует сконфигурировать с помощью страницы свойств для работы в отдельном адресном пространстве, что позволит предотвратить дальнейшие отказы до выяснения их причины. На Экране 1 показана страница Properties моего тестового приложения MTSTester.

    Надо отметить, что Web-узлы, на которых установлены лишь IIS, не требуется часто перезагружать или перенастраивать, поскольку в этом случае сервер функционирует очень устойчиво. Например, у моего провайдера 17 надежно работающих серверов IIS 4.0 под управлением Windows NT 4.0 Server с SP5, на которых выполняются приложения HTML, Active Server Pages (ASP) и COM.

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

    Управление COM-объектами требует понимания особенностей их работы. Поскольку они представляют собой откомпилированный программный модуль, изучить их код и алгоритмы, как правило, не представляется возможным, а это затрудняет контроль за работой приложения и выявление причин возникающих отказов. Например, можно использовать приобретенные COM-объекты, разработчики которых не предоставили доступа к исходным текстам. Загрузив эти объекты, процесс IIS исполняет их код в своем адресном пространстве.

    Хотя мой Internet-провайдер прилагает все усилия к тому, чтобы его COM-объекты работали надежно, во второй половине 1998 года я заметил, что мой узел в течение некоторого времени функционирует нормально, а затем его производительность постепенно падает до нуля. Снижение производительности имело место в течение нескольких недель или месяцев и носило беспорядочный характер. Когда я вызвал специалиста по технической поддержке, он выяснил, что мой узел работает во внепроцессном режиме. Как только его перевели на работу во внутрипроцессном режиме, все стало на свои места.

    После случившегося я разговаривал с несколькими людьми, которым пришлось столкнуться с подобной ситуацией. Мы сошлись на том, что приложения IIS 4.0, работающие во внепроцессном режиме, часто вызывают такого рода проблемы, которые заставляют перезагружать сервер. Я знаю администраторов, которые запускают приложения intranet в фоновом режиме для предотвращения отказа серверов, но при этом периодически перезагружают их. Такой подход помогает, так что администраторам приходится мириться с неприятностями.

    Для управления внепроцессными и внутрипроцессными компонентами IIS 4.0 задействует Microsoft Transaction Server (MTS), формирующий так называемые пакеты MTS. Эти пакеты представляют собой контейнеры для одного или нескольких COM-компонентов, и они же определяют пространство имен этих компонентов. Управление пакетами MTS возложено на программу mtx.exe. Контролировать работу экземпляров mtx.exe, создаваемых MTS при запуске фоновых приложений, можно с помощью утилиты Task Manager.

    Желая повысить производительность, администраторы запускают пакеты MTS в адресном пространстве процесса IIS (для этого необходимы

    ЭКРАН 2. Конфигурирование запуска пакета MTS.

    административные привилегии MTS Explorer). Пакеты MTS могут выполняться в рамках серверного процесса (так называемые серверные пакеты) или внутри процесса вызывающего их приложения. С помощью страницы свойств можно сконфигурировать пакет для работы в рамках процесса inetinfo.exe. Чтобы открыть страницу свойств, следует запустить MTS Explorer из меню Programs, открыть папку Computers, папку необходимого компьютера, а затем папку Packages Installed. После этого нужно выбрать настраиваемый пакет и открыть его страницу свойств. На вкладке Activation, как показано на Экране 2, следует установить переключатель Library Package и нажать кнопку ОК. После такой операции объекты пакета будут работать в адресном пространстве вызывающего приложения (inetinfo.exe в случае IIS).

    Чтобы изолировать некорректно работающие приложения IIS, нужно изменить настройки используемых пакетов MTS и убедиться, что они работают как серверные (т. е. установлен переключатель Server Packages), а не как библиотечные. В результате пострадает производительность, но IIS останется работоспособным в случае отказа объекта MTS.

    IIS Exception Monitor

    Служба IIS Exception Monitor помогает администраторам выявлять причины сбоя в работе IIS. Этот инструмент предназначен для контроля за работой IIS и исправления ошибок в случае нарушений в работе сервера. При этом тип выполняемой диспетчером операции зависит от его конфигурации.

    О том, как загрузить IIS Exception Monitor, рассказано в статье Microsoft «INFO: Troubleshooting Exceptions in Internet Server Products» (http://support.microsoft.com/support/kb/ articles/q160/3/60.asp), где есть ссылка на страницу загрузки и документации. Я настоятельно рекомендую загрузить документацию — она поможет разобраться, как работает это приложение. В файле README, который входит в комплект поставки, тоже содержится полезная информация об этом продукте.

    Процедура установки IIS Exception Monitor проста и занимает всего несколько минут. Для ее выполнения нужно запустить на сервере IIS программу ixcptmon.exe. через меню Programs. Исполняемый файл находится в каталоге, куда загружалась программа (по умолчанию — C:\ixcptmon). После запуска программы дальнейшие действия подскажет мастер установки.

    Запустив IIS Exception Monitor, нужно в первом диалоговом окне нажать на кнопку Next. Во втором диалоговом окне следует установить переключатель Yes, Verify the IIS symbols that I have installed, а затем опять нажать Next. В результате этих действий диспетчер исключений проверит систему и выяснит, какие символьные файлы необходимы. Эти файлы содержат данные, которые нужны диспетчеру для отладки процесса IIS, — они позволяют ему выявить источник ошибок.

    ЭКРАН 3. Экран со списком файлов, необходимых для отладки IIS.

    Выяснив, какие символьные файлы требуются системе, диспетчер отобразит их список, показанный на Экране 3. Состав списка зависит от конкретной конфигурации. По окончании процедуры анализа системы следует установить флажок Determine which symbol packages can be installed from Microsoft’s Internet Site и нажать Next. В открывшемся диалоговом окне Download Symbols нужно выбрать первый символьный файл в списке и щелкнуть мышью на кнопке Download, а затем, чтобы загрузить файл, — на кнопке Next. Последовательно выполняя эту операцию, загрузите все нужные файлы (процедура может продолжаться несколько минут). Как только процесс загрузки файлов завершится, программа предложит установить их.

    Чтобы начать сеанс IIS Exception Monitor, нужно снова запустить ixcptmon.exe. Если программа все еще работает после установки символьных файлов, стоит воспользоваться текущим сеансом. В случае повторного запуска в диалоговом окне Check Symbols следует установить переключатель No, I am confident that the symbols are installed correctly, а затем нажать кнопку Next.

    В открывшемся диалоговом окне Process Options нужно указать тип процесса, который предстоит контролировать. Можно выбрать компонент, выполняющийся внутри процесса inetinfo.exe (переключатель In Process), приложение, которое должно исполняться в отдельном адресном пространстве (Out of Process), или любой другой процесс (Other Process). Установив переключатель In Process, нужно щелкнуть кнопкой Next, чтобы открыть диалоговое окно Session Options.

    Параметры диалогового окна Session Options определяют, как будет работать IIS Exception Monitor. Предлагается два варианта: выбрать режим контроля в одном сеансе или рекурсивный режим Recursive Mode для мониторинга процессов до момента возникновения неполадок в работе сервера. Когда IIS Exception Monitor обнаружит ошибку в рекурсивном режиме, он сделает запись в протоколе, остановит и перезапустит процесс inetinfo.exe, а затем возобновит мониторинг. Если в этом отказоустойчивом режиме диспетчер выявит серьезную ошибку, он остановит IIS и перезагрузит сервер.

    Включить рекурсивный режим можно двумя способами: установить в диалоговом окне Session Options флажок Enable Recursive Mode либо запустить сценарий ixcptmon.vbs с параметром командной строки /r. Этот же параметр позволяет отключить рекурсивный режим. В диалоговом окне Session Options также можно ввести адрес, по которому будут автоматически отправляться оповещения об ошибке (командой net send). Для этого в текстовом поле Notify Admin нужно ввести имя компьютера или пользователя. Если же в системе установлена и сконфигурирована библиотека Collaboration Data Objects (CDO), для оповещения можно использовать электронную почту. Имя компьютера или адрес электронной почты задается с помощью ключа командной строки /notify.

    Переключатель Manual диалогового окна Session Options позволяет запустить диспетчер исключений в ручном режиме (например, для выполнения работ, связанных с сопровождением). Этот режим пригодится при работе со специалистом службы технической поддержки Microsoft — он позволит ему получить удаленный доступ к неисправному серверу и принять участие в решении проблемы.

    Выбрав параметры в диалоговом окне Session Options, нужно щелкнуть мышью на кнопке Next, затем в открывшемся диалоговом окне Start Monitoring нажать Run This Monitoring Session. Когда IIS Exсeption Monitor запустит файл ixcptmon.vbs с соответствующими переключателями, начнется сеанс мониторинга. После загрузки сценария ixcptmon.vbs откроется окно сеанса командной строки. Не стоит его закрывать — оно необходимо для работы сценария. После запуска сеанса следует нажать кнопку Next, чтобы открыть окно Session Status. Это окно обеспечивает пользовательский интерфейс к процессу IIS Exception Monitor.

    ЭКРАН 4. Список журналов, созданных, IIS Exception Monitor.

    Из диалогового окна Session Status можно контролировать ход активного сеанса мониторинга или просматривать файлы журналов предыдущих сеансов. Как показано на Экране 4, нужно выбрать созданный диспетчером журнал, а затем открыть его, нажав кнопку View Log. Перед просмотром журнала процесс мониторинга следует остановить. Для остановки мониторинга, а также для остановки и перезапуска IIS нужно открыть окно командной строки диспетчера и нажать клавиши CRTL+C. После этого можно вновь запустить IIS Exception Monitor и приступать к просмотру журнала.

    ЭКРАН 5. Окно просмотра журнала IIS Exception Monitor.

    Кнопка View Log диалогового окна Session Status открывает изображенное на Экране 5 окно Log, которое предоставляет на выбор несколько вариантов просмотра информации о статусе сеанса протоколирования и IIS. Нужный вариант просмотра можно выбрать, нажимая кнопки окна.

    Отключение пользовательских ошибок IIS8 для классического ASP — Потенциальная ошибка в IIS?

    Я думаю, что нашел ошибку в системе ошибок страниц IIS.

    Примечание: — Я не использую .NET страницы ошибок — это установлено значение Выкл

    Проблема:

    Когда страница пользовательской ошибки настройки для (классический ASP) ответ 500.100 код, IIS всегда отправляет страницу пользовательской ошибки, даже если errorMode установлен в Подробный. Единственный способ заставить IIS отправить сообщение об ошибке — явно удалить запись в файле web.config.

    Примечание — следующее делает не работу (которая работает для всех других кодов):

    Мой сценарий:

    • IIS 8 (Я не знаю, существует ли проблема в пожилом возрасте версии IIS)
    • Сайт работает с .NET 2.0 — Классический трубопроводные
    • Характеристика Делегирование на страницах ошибок, установленных в только для чтения
    • Ошибка страница настройки в IIS следующим образом (за счет делегирования признака выше, эти данные являются не в web.config):
      • 404 — /path/to/404.htm — ExecuteURL
      • 500 — /path/to/500.htm — ExecuteURL
      • 500,100 -/путь/к/500 .htm — ExecuteUrl

    Отключение пользовательских ошибок:

    Для того, чтобы отключить пользовательские ошибки, все, что мне нужно сделать, это:

    • нагрузки IIS
    • Load Error Pages
    • Нажмите Edit Feature Settings
    • Выберите Detailed Errors

    Это успешно работает для всех кодов кроме Классический ASP 500 ошибок (код состояния 500,100).

    Единственный способ, которым я могу получить надлежащую ошибку Классический ASP заключается в установке следующее (что требует от меня, чтобы изменить делегирование функций на чтение/запись):

    Резюме

    It кажется, что если настраивается страница пользовательской ошибки 500.100, то установка Подробные ошибки в true не Работа для классических ошибок ASP 500.

    Является ли это ошибкой или что-то не хватает?

    Создан 19 апр. 13 2013-04-19 16:27:30 gregpakes

    Iis о специальных сообщениях об ошибках

    Вкладка Заголовки HTTP.

    На вкладке Заголовки HTTP окна свойств web-узла вы можете:

    • задействовать работу с истечением срока годности содержимого (content expiration) для данного сайта;
    • задать нестандартные заголовки HTTP, возвращаемые сервером клиентам в ответ на запросы HTTP;
    • включить и задать рейтинги содержимого Консультативного Совета по развлекательному программному обеспечению (RSAC, Recreational Software Advisory Council);
    • задать дополнительное сопоставление MIME для данного web-узла.

    Истечение срока годности содержимого

    Если вы разрешаете на сайте применение срока годности содержимого, то при запросе клиентом файла с этого сайта сервер возвращает заголовки HTTP с информацией о дате истечения срока годности содержимого. После этого клиент может решить, следует ли ему скачать более новую версию файла или же использовать имеющуюся копию из кэша браузера клиента.

    Если ваш сайт содержит часто меняющуюся информацию (например, ежечасные новости), то вы можете принудить клиента забирать с сервера только свежие копии файлов (и никогда не использовать кэшированные версии файлов) при помощи переключателя Содержимое веб-узла должно: (положение истекает немедленно).

    Специальные заголовки HTTP

    Эта возможность, понятная лишь знатокам, позволяет определять нестандартные заголовки HTTP, возвращаемые сервером в ответ на запросы HTTP клиентов. Это средство можно применять для работы брандмауэров и прокси-серверов; с его помощью можно включать или отключать некоторые функциональные возможности сеансов HTTP.

    Оценка содержимого (рейтинг содержимого) используется, чтобы включить и задать рейтинги содержимого Консультативного Совета по развлекательному программному обеспечению (RSAC). При помощи настроек можно задать рейтинг сайта относительно насилия, секса и словесного содержимого; эти рейтинги используются на сайтах, содержащих материалы, нежелательные для просмотра детьми.

    Глобальное сопоставление MIME для сервера IIS обсуждалось в разделе, посвященном администрированию на уровне сервера. При администрировании на уровне сайта вы можете задать дополнительное сопоставление MIME, относящееся к конкретному web-узлу.

    Вкладка Специальные ошибки.

    Благодаря вкладке Специальные ошибки вы можете задать способ, при помощи которого ваш сервер будет генерировать сообщения об ошибках HTTP при попытках пользователей осуществлять доступ к заданному web-узлу. По спецификации HTTP первая строка заголовка, возвращаемая web-сервером в ответ на запрос клиента, должна содержать число и связанное с ним сообщение, обозначающее статус запроса.

    Эти трехзначные числа называются кодами статуса HTTP и классифицируются на несколько категорий:

    1. от 200 до 299. Произошла успешная транзакция HTTP. (Самый обычный код статуса — 200 ОК).

    2. от 300 до 399. Произошло перенаправление к другому URL.

    3. от 400 до 499. Произошла ошибка. Вот примеры ошибок:

    • 400 Bad Request (Плохой запрос). Сервер не может понять синтаксис запроса.
    • 401 Unauthorized (Нет авторизации). Удостоверения пользователя не позволяют ему войти в систему на сервер.
    • 403 Forbidden (Запрещено). По какой-то причине, отличной от удостоверений для входа, доступ запрещен (например, для данного клиента применено ограничение по IP-адресу или для доступа к этому серверу необходимо использовать SSL).
    • 404 File Not Found (Файл не найден). Файл, к которому производится попытки доступа, не существует на сервере (или перемещен в другое место, или переименован).
    • от 500 до 599. Произошла ошибка сервера или запрашиваемая функциональная возможность не реализована.

    IIS сконфигурирована так, чтобы возвращались не коды статуса HTTP (от 400 до 499) с краткими сообщениями, а созданные заранее страницы HTML, содержащие более подробную информацию. Эти «файлы ошибок» находятся на сервере в папке \%systemroot%\help\iishelp\common и вы, если хотите, можете их изменять. А можно поступить по-другому: выбрать один из этих «файлов ошибок» в странице с вкладкой Специальные ошибки и щелкнуть кнопку Изменить. Теперь вы можете задать, чтобы при возникновении ошибок сервер возвращал либо стандартные коды статуса и сообщения HTTP, либо любой предназначенный для этого файл, расположенный или в локальной папке, или в сетевом разделяемом ресурсе. В файлы с сообщениями об ошибках можно, например, поместить какие-либо элементы, помогающие клиентам найти нужную им страницу. B IIS применяются более подробные сообщения об ошибках, нежели предусмотренные спецификацией HTTP. Например, код ошибки HTTP 401, означающий в HTTP просто отсутствие авторизации, представлен в IIS группой кодов от 401.1 до 401.5, соответствующих различным причинам отказа сервера принять удостоверения клиента.

    Вкладка Server Extensions 2002.

    Вкладка Server Extensions 2002 позволяет перейти к настройке серверных расширений FrontPage, о которых говорилось ранее. Что бы открыть окно установок FrontPage Server Extensions, нажмите кнопку Settings.

    настраиваемое сообщение об ошибке в IIS

    В IIS 5.1 я установил безопасность веб-сайта на основные проверки подлинности и я установил страницу для пользовательской ошибки в IIS, которая направлена на c:test.ASP-файл.

    Когда пользователь пытается получить доступ к веб-сайту, появляется экран имя пользователя и пароль и после ввода неправильного пароля 3 раза, система показывает пользовательскую страницу ошибки, которая прекрасна, но почему система запрашивает имя пользователя и пароль снова (в течение трех раз)?

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

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

    Так или иначе обойти его?

    2 ответа

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

    Что касается экрана входа в систему, как он отображается? Что это? Похоже, что это будет появляться независимо от того, что еще происходит.

    Эта проблема была решена путем добавления html-страницы для ошибок 401 и 402.

    Илон Маск рекомендует:  Что такое код java
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL