Как исправить ошибку HTTP 500.0 - Internal Server Error при публикации HTTP-сервисов 1С на IIS?

← На главную

При первой публикации собственного HTTP-сервиса 1С на веб-сервере Internet Information Services (IIS) разработчики часто сталкиваются с пугающим сообщением Ошибка HTTP 500.0 - Internal Server Error или сопутствующей ошибкой HTTP 401.2 - Unauthorized. Проблема осложняется тем, что встроенный отладчик 1С на этом этапе не срабатывает, так как веб-запрос "падает" еще на подступах к платформе, внутри самого веб-сервера IIS.

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

Шаг 1. Проверяем регистр символов в URL и структуру адреса

Начнем с самой банальной, но критически важной детали, на которую часто не обращают внимания. Веб-сервер IIS и платформа 1С крайне чувствительны к регистру символов в путях URL. Если ваша информационная база опубликована под именем UTP, а корневой URL вашего HTTP-сервиса в конфигураторе задан как Test, то обращение по адресу http://localhost/utp/hs/test вернет ошибку.

Давайте проанализируем правильную структуру формирования адреса для HTTP-сервиса 1С:

http://[ИмяСервера]/[ИмяПубликации]/hs/[КорневойURLСервиса]/[ШаблонURL]

Разберем это правило по шагам:

ИмяПубликации — имя виртуального каталога, которое вы указали в конфигураторе при публикации на веб-сервере (например, UTP).
hs — обязательный системный префикс, указывающий веб-серверу, что запрос адресован именно к HTTP-сервисам (в отличие от ws для SOAP Web-сервисов).
КорневойURLСервиса — свойство "Корневой URL" непосредственно вашего объекта конфигурации "HTTP-сервис" (например, Test).
ШаблонURL — путь, соответствующий вашему шаблону URL внутри HTTP-сервиса (например, get или data). Если шаблон настроен как /get, то итоговый адрес должен заканчиваться именно так.

Таким образом, вместо неверного пути http://localhost/utp/hs/test мы должны использовать строго соответствующий регистру адрес: http://localhost/UTP/hs/Test/get.

Шаг 2. Настраиваем авторизацию в IIS и файле default.vrd

Если после исправления регистра в URL вместо ошибки 500.0 вы получили Ошибка HTTP 401.2 - Unauthorized, это означает, что веб-сервер требует проверки подлинности пользователя, но не может её выполнить с текущими настройками.

Если в этот момент просто отключить в настройках IIS проверку подлинности Windows и оставить только "Анонимный доступ", мы снова вернемся к ошибке 500.0. Происходит это потому, что IIS пытается зайти в базу под анонимным пользователем, но в самой базе 1С настроен список пользователей с паролями. Механизм HTTP-сервисов в 1С спроектирован так, что он не может интерактивно отобразить диалоговое окно ввода логина и пароля, как это делает Web-клиент. В результате 1С аварийно завершает сессию, а IIS транслирует это как ошибку 500.0.

Выясним, как правильно решить эту проблему. У нас есть два пути:

Вариант А. Прописать сервисного пользователя по умолчанию

Мы можем жестко указать учетную запись 1С, под которой будут выполняться все запросы к HTTP-сервису. Для этого найдем в папке публикации (по умолчанию C:\inetpub\wwwroot\UTP) конфигурационный файл default.vrd и откроем его через любой текстовый редактор. Нам необходимо отредактировать тег point, добавив в него атрибуты пользователя usr и пароля pwd:


<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/UTP"
       ib="File="C:\Bases\UTP";"
       usr="WebUser"
       pwd="SecretPassword">
    <ws/>
    <httpServices>
        <service name="Test" rootUrl="Test" enable="true"/>
    </httpServices>
</point>

Убедимся, что у пользователя WebUser в базе 1С достаточно прав для выполнения операций в HTTP-сервисе, а в его роли отмечено право "Администрирование данных" или специализированные права на работу с HTTP-сервисами.

Вариант Б. Использовать Basic-авторизацию в запросе

Если жестко прописывать пользователя в файле конфигурации нельзя из соображений безопасности, мы должны передавать авторизационные данные непосредственно в заголовке HTTP-запроса от клиента (например, из утилиты Postman или сторонней системы). Для этого в заголовки запроса добавляется стандартный заголовок Authorization с типом Basic, где логин и пароль пользователя 1С передаются в кодировке Base64.

Шаг 3. Установка NTFS-прав для группы пользователей IIS

Ошибка 500.0 очень часто оказывается следствием банальной нехватки прав доступа операционной системы Windows к исполняемым файлам 1С и каталогу базы данных (при файловом варианте работы).

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

Папка исполняемых файлов платформы 1С. Перейдем в свойства папки C:\Program Files\1cv8 (или конкретной версии платформы, например C:\Program Files\1cv8\8.3.22.1709\bin). На вкладке "Безопасность" добавим группу пользователей IIS_IUSRS и предоставим им права "Чтение и выполнение", "Список содержимого папки" и "Чтение".
Папка с файловой базой данных. Если ваша база файловая, перейдем в каталог базы данных. Добавим группу IIS_IUSRS и предоставим ей права "Изменение", "Чтение и выполнение", "Список содержимого", "Чтение", "Запись". Это критично, так как IIS должен иметь физическую возможность вносить изменения в файл базы данных 1Cv8.1CD и создавать файлы блокировок 1Cv8.1CL.
Каталог публикации IIS. Убедимся, что группа IIS_IUSRS имеет права на чтение файлов в папке C:\inetpub\wwwroot\UTP, где лежат конфигурационные файлы default.vrd и web.config.
Системный каталог временных файлов Temp. При обработке веб-запросов платформа 1С активно сериализует данные и создает временные файлы в системной папке C:\Windows\Temp. Перейдем в свойства папки Temp и предоставим группе IIS_IUSRS права на чтение, запись и изменение. Без этих прав вы гарантированно получите ошибку 500.0 при попытке вернуть из HTTP-сервиса большой объем данных.

Шаг 4. Настройка разрядности пула приложений IIS

Рассмотрим аппаратную причину возникновения сбоя. Если вы опубликовали HTTP-сервис из 32-разрядного конфигуратора 1С (x86) на 64-битной операционной системе Windows, IIS попытается запустить соответствующую 32-битную библиотеку wsapi.dll (или wsap24.dll).

По умолчанию 64-битный веб-сервер IIS запрещает исполнение 32-битных расширений ISAPI в стандартном пуле приложений, что моментально вызывает ошибку 500.0 при первом же обращении.

Для исправления этой ситуации выполним следующие действия:

Откроем Диспетчер служб IIS.
В левом дереве навигации перейдем в раздел Пулы приложений (Application Pools).
Найдем пул, на котором работает наша публикация (как правило, это DefaultAppPool).
Кликнем по нему правой кнопкой мыши и выберем пункт Дополнительные параметры (Advanced Settings).
В строке Разрешены 32-разрядные приложения (Enable 32-Bit Applications) установим значение True.
Нажмем "ОК" и перезапустим пул приложений.

Шаг 5. Конфликт версий платформы 1С на одном веб-сервере

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

Если обе публикации привязаны к одному и тому же пулу приложений IIS, веб-сервер не может одновременно загрузить в память разные версии библиотек (например, от платформы 8.3.18 и 8.3.22). Тот сервис, к которому обратились первым после перезапуска IIS, займет пул, а второй начнет выдавать ошибку 500.0.

Для решения этой проблемы разделим базы по разным пулам приложений:

В Диспетчере служб IIS перейдем в Пулы приложений и нажмем в правом меню Добавить пул приложений.... Создадим новый пул с именем, например, AppPool_UTP.
Перейдем в левом дереве к нашей публикации UTP.
В правом меню выберем Дополнительные параметры.
В строке Пул приложений заменим стандартный пул на наш только что созданный AppPool_UTP.
Убедимся, что в корневых настройках сервера IIS в разделе Ограничения ISAPI и CGI (ISAPI and CGI Restrictions) разрешена работа библиотек wsap24.dll для обеих версий платформы.

Шаг 6. Глубокая диагностика через просмотр событий Windows

Если все вышеперечисленные шаги выполнены, но ошибка 500.0 сохраняется, нам необходимо локализовать причину с помощью системных логов Windows. Код 500.0 — это слишком общий ответ веб-сервера. Чтобы узнать технический подкод ошибки, выполним следующие шаги:

Нажмите сочетание клавиш Win + R, введите eventvwr.msc и нажмите Enter для открытия "Просмотра событий".
Перейдите по пути: Журналы Windows -> Приложение.
Отфильтруйте журнал по источникам IIS-W3SVC-WP или 1C:Enterprise.
Изучите ошибки, возникшие в момент вашего запроса к сервису. Например, код ошибки 0x800700c1 четко укажет на проблему несовместимости разрядности (32/64 бит), а ошибки файловой системы укажут на конкретный путь, к которому у IIS нет прав доступа.

Дополнительно мы можем включить отображение подробных ошибок непосредственно в браузере. Для этого в диспетчере IIS перейдем в настройки нашей публикации, откроем раздел Страницы ошибок (Error Pages) -> Изменить параметры функции (Edit Feature Settings) и установим переключатель в положение Подробные ошибки (Detailed errors). Теперь при отправке локального запроса IIS выдаст детальную страницу с указанием конкретного модуля и обработчика, вызвавшего сбой.