Как исправить ошибку "Обнаружено потенциально опасное значение Request.Path" при работе 1С через веб-сервер IIS?

← На главную

При работе с базами данных «1С:Предприятие», опубликованными на веб-сервере Microsoft IIS или Apache, системные администраторы часто сталкиваются с ошибкой «HttpException (0x80004005): Обнаружено потенциально опасное значение Request.Path, полученное от клиента». Эта проблема обычно проявляется при попытке открыть документы или определенные разделы системы через веб-клиент или тонкий клиент с использованием лаунчера по протоколу HTTP/HTTPS. Особенно остро вопрос встает при переходе с 32-битной на 64-битную версию платформы или при обновлении операционной системы сервера.

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

Почему возникает эта ошибка?

Проанализируем техническую сторону вопроса. Ошибка генерируется модулем защиты ASP.NET (включая расширения веб-клиента). Система безопасности веб-сервера IIS по умолчанию блокирует запросы, содержащие определенные спецсимволы в URL-адресе. Платформа 1С активно использует символ двоеточия : и другие знаки (требующих иногда очистки кэша) для передачи внутренних идентификаторов объектов и навигационных ссылок в строке запроса. Когда IIS встречает такой символ в пути запроса (Request.Path), он расценивает это как потенциальную атаку (например, попытку межсайтового скриптинга) и обрывает соединение. Разбор других неочевидных проблем при настройке IIS приведен в статье об особенностях работы веб-сервисов 1С на IIS.

Решение 1: Изменение режима управляемого конвейера пула приложений

Наиболее популярным и быстрым решением, которое помогает большинству пользователей, является перевод пула приложений IIS из интегрированного режима в классический. Разберем этот процесс по шагам:

Запустим Диспетчер служб IIS (Internet Information Services Manager).
В дереве соединений выберем раздел «Пулы приложений» (Application Pools).
Найдем пул, который используется для публикации вашей базы 1С (обычно это DefaultAppPool или специально созданный пул).
Нажмем на него правой кнопкой мыши и выберем пункт «Основные настройки» или выберем «Дополнительные параметры» в правой панели.
Найдем параметр «Режим управляемого конвейера» (Managed Pipeline Mode) и изменим его значение с Integrated на Classic.
Перезапустим веб-сервер или сам пул приложений для вступления изменений в силу.

Почему это помогает? В режиме Classic запросы обрабатываются через старый конвейер ISAPI. Это позволяет расширению wsisapi.dll получать управление до того, как сработают строгие фильтры безопасности ASP.NET, характерные для интегрированного режима.

Решение 2: Тонкая настройка web.config (без смены режима пула)

Если по каким-то причинам вы хотите оставить пул приложений в режиме Integrated (который является более современным), мы можем отредактировать файл web.config, находящийся в каталоге публикации вашей информационной базы. Нам нужно разрешить использование спецсимволов и изменить режим валидации запросов.

Рассмотрим пример правильного содержимого секции system.web в файле web.config:


<system.web>
    <httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="" relaxedUrlToFileSystemMapping="true" />
</system.web>

Проанализируем, за что отвечают эти параметры:

requestValidationMode="2.0" — заставляет сервер использовать менее строгую логику проверки запросов, характерную для старых версий .NET Framework.
requestPathInvalidCharacters="" — этот атрибут обнуляет список запрещенных символов в пути запроса, что позволяет 1С передавать двоеточия и другие знаки.
relaxedUrlToFileSystemMapping="true" — позволяет использовать более свободное сопоставление URL с файловой системой Windows.

Решение 3: Настройка сопоставления обработчиков

Иногда ошибка возникает из-за некорректного сопоставления библиотеки расширения 1С. Рассмотрим, как правильно настроить обработчик wsisapi.dll:

В Диспетчере IIS выберем конкретный «сайт» (опубликованную базу).
Откроем раздел «Сопоставления обработчиков» (Handler Mappings).
Найдем сопоставление для расширения 1С (обычно называется 1C Web-service Extension).
Нажмем «Изменить» (Edit).
Проверим, что в поле «Путь запроса» указана звездочка *, а в поле «Исполняемый файл» — верный путь к 64-битной библиотеке (для 64-битного сервера это C:\Program Files\1cv8\номер_версии\bin\wsisapi.dll).
Нажмем кнопку «Ограничения запроса» и на вкладке «Сопоставление» снимем галочку «Вызывать обработчик только при сопоставлении запроса с:».

Решение 4: Отключение управляемого кода в пуле приложений

Поскольку библиотека 1С wsisapi.dll написана на C++ и не является управляемым .NET-приложением, наиболее архитектурно верным решением будет полная очистка пула приложений от влияния .NET. Проанализируем, как это сделать:

В настройках пула приложений установите параметр «Версия среды .NET CLR» (.NET CLR Version) в значение «Без управляемого кода» (No Managed Code). Это полностью отключает конвейер ASP.NET для данного пула, тем самым устраняя причину проверки Request.Path на корню. Это также может дать небольшой прирост производительности веб-сервера за счет исключения лишних проверок.

Решение 5: Изменение режима использования модальности в 1С

В некоторых случаях, зафиксированных пользователями, проблема может быть связана с тем, как платформа 1С обрабатывает модальные окна в браузере. Выясним, как это изменить на уровне конфигурации:

Откроем конфигуратор вашей информационной базы.
В свойствах корня конфигурации найдем параметр «Режим использования модальности».
Установим значение «Использовать с предупреждениями» вместо «Использовать».
Аналогично можно поступить с параметром «Режим использования синхронных вызовов расширений платформы и внешних компонент».

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

Важное примечание для 64-битных систем: Если вы используете 64-битную версию сервера 1С и соответствующую библиотеку wsisapi.dll, убедитесь, что в дополнительных параметрах пула приложений IIS свойство «Разрешить 32-разрядные приложения» (Enable 32-Bit Applications) установлено в значение False. В противном случае 64-битная библиотека не сможет загрузиться в 32-битном рабочем процессе IIS.