При работе с веб-клиентом 1С через сервер IIS (Internet Information Services) пользователи часто сталкиваются с неприятной ситуацией: авторизация проходит успешно, начальный экран загружается, но при попытке открыть любой раздел (например, «Операции», «Календарь» или отчеты) сервер выдает стандартное сообщение Runtime Error. Эта ошибка скрывает под собой реальную техническую проблему, связанную с тем, как IIS обрабатывает URL-запросы, содержащие специфические для 1С символы. В рамках этой статьи мы подробно разберем, почему это происходит, и проанализируем несколько проверенных способов решения проблемы.
Прежде чем переходить к настройкам, давайте разберем природу проблемы. Платформа 1С:Предприятие при работе через веб-интерфейс активно использует сложные URL-адреса. В частности, для навигации и работы с наборами данных (OData) могут использоваться двоеточия (:), точки с запятой и другие спецсимволы.
По умолчанию в IIS пулы приложений настроены на работу под управлением среды .NET Framework (Managed Code). Когда запрос поступает на сервер, он проходит через конвейер обработки ASP.NET. Этот конвейер содержит встроенные фильтры безопасности, которые блокируют любые подозрительные, с их точки зрения, символы в адресе строки. Поскольку расширение 1С для веб-сервисов (модуль wsisapi.dll) написано на нативном коде (C++), ему фактически не нужны функции управления .NET. Столкновение «строгих» правил ASP.NET и специфической логики формирования ссылок 1С и приводит к ошибке Runtime Error.
Проанализируем самый эффективный и рекомендуемый способ, который помог большинству участников обсуждения. Суть его заключается в том, чтобы исключить из цепочки обработки запроса среду .NET, которая и инициирует блокировку.
Рассмотрим пошагово, как изменить настройки пула приложений:
DefaultAppPool, если база опубликована в нем).Важное замечание: Поскольку расширение 1С является нативным модулем, это изменение никак не повредит работе базы, но уберет лишние проверки со стороны ASP.NET, мешающие навигации.
Если по каким-то причинам мы не хотим менять режим работы пула приложений, или если ошибка сохраняется даже в режиме «No Managed Code», нам необходимо вручную разрешить использование спецсимволов. Для этого мы внесем правки в файл конфигурации веб-приложения web.config, который создается в папке публикации базы 1С.
Разберем, какие именно параметры нужно изменить. Файл обычно находится по пути вида C:\inetpub\wwwroot\ИмяВашейБазы\web.config. Нам нужно добавить или отредактировать секцию <system.web>.
Пример настройки, разрешающей использование двоеточия и других символов:
<configuration>
<system.web>
<httpRuntime requestPathInvalidCharacters=",%,&,\,?" />
</system.web>
</configuration>
Обратите внимание, что в атрибуте requestPathInvalidCharacters мы перечисляем только те символы, которые запрещены. Удалив оттуда двоеточие (:), мы тем самым разрешаем его использование в URL.
Также полезно добавить настройку allowDoubleEscaping, которая позволяет серверу корректно обрабатывать ссылки с двойным экранированием символов:
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true" />
</security>
</system.webServer>
Важно: Помните, что при повторной публикации информационной базы из конфигуратора 1С файл web.config может быть перезаписан, и эти настройки придется вносить заново.
Иногда корень проблемы кроется в неправильной привязке модуля расширения 1С. Проверим, правильно ли настроено сопоставление обработчиков для расширения .1cws или .1crs.
Для этого в диспетчере IIS перейдем в настройки конкретного сайта (вашей публикации) и откроем раздел Сопоставления обработчиков (Handler Mappings). Убедимся, что запись 1C Web-service Extension указывает на актуальный файл wsisapi.dll, который находится в папке bin установленной платформы 1С.
Путь для 64-битной версии обычно выглядит так: C:\Program Files\1cv8\8.3.X.XXXX\bin\wsisapi.dll. Если используется 32-битная платформа на 64-битной Windows, путь будет содержать Program Files (x86).
Если вышеуказанные способы не помогают, нам нужно увидеть реальный текст ошибки вместо общей заглушки Runtime Error. Рассмотрим, как включить подробный вывод ошибок для диагностики.
web.config можно временно установить режим <customErrors mode="Off"/>.После этого при возникновении сбоя вместо стандартного текста вы увидите конкретный код ошибки (например, 404.15 или 500.19) и описание того, какой именно модуль или фильтр заблокировал запрос. Это даст точное понимание, в какую сторону двигаться дальше.
Проанализируем еще два критически важных момента, которые часто упускают при настройке:
1. Разрядность пула: Если вы используете 32-битную версию платформы 1С, вам необходимо разрешить выполнение 32-разрядных приложений в пуле. В Дополнительных параметрах (Advanced Settings) пула приложений установите значение True для параметра Разрешить 32-разрядные приложения (Enable 32-Bit Applications).
2. Права доступа: Пользователь, от имени которого работает пул приложений (обычно это IIS AppPool\ИмяПула), должен иметь права на Чтение и выполнение папки с платформой 1С (каталог bin). Без этого IIS не сможет загрузить библиотеку wsisapi.dll, что также приведет к Runtime Error на этапе обращения к модулю.
Подводя итог, можно сказать, что связка 1С и IIS требует тонкой настройки безопасности. Использование режима No Managed Code является наиболее стабильным и простым решением, так как оно минимизирует конфликты между веб-сервером и платформой «1С:Предприятие».