Почему HTTP-сервис 1С на IIS возвращает ошибку 404 и как ее исправить?

← На главную

Публикация базы данных на веб-сервере IIS (Internet Information Services) — стандартная задача для интеграции 1С с внешними системами. Однако часто возникает ситуация, когда веб-клиент и SOAP-веб-сервисы (WS) работают без нареканий, а при обращении к собственному или типовому HTTP-сервису веб-сервер упорно возвращает ошибку 404 (Not Found).

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

Выясняем причину: тип HTTP-запроса и поведение браузера

Разберем типичную ситуацию. Разработчик открывает любимый веб-браузер и вводит в адресную строку URL-адрес своего HTTP-сервиса, например: http://192.168.1.1/erp/hs/TestService. В ответ он видит стандартную страницу ошибки 404.

Почему так происходит? Дело в том, что веб-браузер при вводе адреса в строку всегда отправляет стандартный GET-запрос. Если в вашей конфигурации 1С для данного HTTP-сервиса определен только метод POST (или PUT, DELETE, PATCH), то платформа 1С просто не найдет подходящего обработчика для GET-запроса по указанному пути. В результате веб-сервер вернет код состояния 404, сообщая, что запрашиваемый ресурс по данному методу не существует.

Выяснив эту особенность, мы приходим к логичному выводу: тестировать HTTP-сервисы (особенно отличные от GET) через обычный браузер нельзя. Для этих целей необходимо использовать специализированные инструменты:

Postman или Insomnia — мощные графические клиенты для создания любых типов HTTP-запросов, настройки заголовков, передачи тела запроса в формате JSON/XML и анализа ответов сервера.
Утилиту командной строки cURL, которая встроена во все современные операционные системы.
Встроенный механизм самой платформы 1С, используя объекты HTTPСоединение и HTTPЗапрос.

Давайте посмотрим на простой пример отправки POST-запроса с помощью встроенного языка 1С:


Соединение = Новый HTTPСоединение("192.168.1.1", , "ИмяПользователя", "Пароль");
Запрос = Новый HTTPЗапрос("/erp/hs/TestService/v1/data");
Запрос.УстановитьТелоИзСтроки("{""status"": ""ping""}", КодировкаТекста.UTF8);

Попытка
    Ответ = Соединение.ОтправитьДляОбработки(Запрос);
    Сообщить("Код состояния: " + Ответ.КодСостояния);
    Сообщить("Ответ: " + Ответ.ПолучитьТелоИзСтроки());
Исключение
    Сообщить("Ошибка отправки запроса: " + ОписаниеОшибки());
КонецПопытки;

Если при использовании Postman или кода 1С вы все равно получаете 404, нам нужно копать глубже и проверить корректность формирования URL.

Шаг 1. Проверяем шаблоны URL и чувствительность к регистру

Адрес HTTP-сервиса в 1С формируется по строго определенным правилам. Структура ссылки выглядит следующим образом:

http://<Хост>/<ИмяПубликации>/hs/<КорневойURL>/<ШаблонURL>

Проанализируем детально каждый элемент этого пути:

hs — фиксированный признак того, что запрос адресован именно к HTTP-сервису (в отличие от ws для SOAP-сервисов).
КорневойURL — свойство корневого HTTP-сервиса, заданное в конфигураторе 1С.
ШаблонURL — путь, прописанный в подчиненном объекте "Шаблон URL" внутри вашего HTTP-сервиса.

Здесь разработчики часто совершают две критические ошибки:

1. Несоответствие шаблона пути. Если корневой URL вашего сервиса — TestService, а внутри него создан шаблон URL с путем /get_info, то запрос по адресу .../hs/TestService вернет ошибку 404! Платформа ожидает точного совпадения всего пути целиком. Вы обязаны отправить запрос на .../hs/TestService/get_info. Если вы хотите, чтобы сервис откликался сразу на корень, в шаблоне пути должен быть явно прописан символ / или пустой путь.

2. Чувствительность к регистру. Роутинг HTTP-сервисов в 1С крайне чувствителен к регистру символов. Если в конфигураторе вы назвали корневой URL как TestService, а в Postman отправляете запрос на testservice или TESTSERVICE, веб-сервер вернет ошибку 404. Убедитесь, что регистр всех символов в URL полностью совпадает с конфигурацией.

Шаг 2. Анализируем файл публикации default.vrd

Если структура URL верна, нам необходимо проверить, знает ли вообще веб-сервер IIS о существовании ваших HTTP-сервисов. Вся информация о публикации базы данных хранится в конфигурационном файле default.vrd, который располагается в физической папке публикации на сервере (например, C:\inetpub\wwwroot\erp\).

Откроем этот файл любым текстовым редактором и внимательно изучим его структуру. Нас интересует секция <httpServices>. Рассмотрим два варианта настройки этой секции.

Вариант первый: автоматическая публикация всех сервисов. В этом случае у узла должен быть установлен атрибут publishByDefault="true":


<httpServices publishByDefault="true">
    <service name="ОбщиеHTTPСервисы" alias="common" enable="true"/>
</httpServices>

Вариант второй: точечная публикация конкретных сервисов. Если автопубликация отключена (publishByDefault="false"), то каждый ваш HTTP-сервис должен быть зарегистрирован вручную отдельной строкой:


<httpServices publishByDefault="false">
    <service name="ТестСервис" alias="TestService" enable="true"/>
    <service name="ИнтеграцияСайт" alias="site_api" enable="true"/>
</httpServices>

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

Шаг 3. Особенности работы с расширениями конфигурации

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

При стандартной публикации базы данных через конфигуратор (или утилиту командной строки webinst) флаг публикации HTTP-сервисов расширений может быть снят. Разберем, как исправить это:

Откройте Конфигуратор от имени администратора.
Перейдите в меню Администрирование -> Публикация на веб-сервере.
Перейдите на вкладку HTTP-сервисы.
Убедитесь, что установлен флаг "Публиковать HTTP-сервисы расширений по умолчанию" (Publish extension HTTP services by default).
Нажмите кнопку Опубликовать для обновления файла default.vrd.

После этого веб-сервер начнет корректно считывать структуру виртуальных ресурсов, описанную в ваших расширениях, и ошибка 404 исчезнет.

Шаг 4. Настройка прав доступа и маскировка ошибок

Иногда веб-сервер IIS или сама платформа 1С могут маскировать ошибку авторизации **401 Unauthorized** под ошибку **404 Not Found**. Это делается из соображений безопасности, чтобы потенциальный злоумышленник не мог сканировать структуру существующих URI-адресов системы.

Чтобы исключить эту проблему, выполним следующие действия:

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

Рассмотрим, как выглядит пример файла default.vrd с указанием пользователя для авторизации:


<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/erp"
       ib="Srvr=&quot;Server1C&quot;;Ref=&quot;erp_db&quot;;usr=&quot;IIS_User&quot;;pwd=&quot;SecretPassword&quot;;">
...
</point>

Шаг 5. Системные настройки IIS и фильтрация ISAPI

Если веб-клиент базы функционирует нормально, но любые обращения к API (как SOAP /ws/, так и HTTP /hs/) стабильно возвращают ошибку 404, проблема может заключаться в глобальных настройках самого IIS.

Веб-сервер IIS передает обработку запросов платформе 1С через специальный модуль расширения — библиотеку wsisapi.dll. Если эта библиотека заблокирована или у IIS нет прав на ее запуск, запросы к сервисам обрабатываться не будут.

Проанализируем шаги по настройке IIS:

Откройте диспетчер служб IIS.
Перейдите на корневой узел сервера и откройте раздел "Ограничения ISAPI и CGI" (ISAPI and CGI Restrictions).
Убедитесь, что в списке присутствует путь к библиотеке wsisapi.dll для используемой вами версии платформы 1С и для нее установлено состояние "Разрешено" (Allowed).
Проверьте права доступа на физическую папку платформы 1С (обычно это C:\Program Files\1cv8\). Учетная запись, от имени которой работает пул приложений IIS (обычно это IIS_IUSRS или NetworkService), должна иметь права на чтение и выполнение файлов в этой директории.

Как отлаживать HTTP-сервисы в 1С?

Когда вы настроили публикацию, избавились от ошибки 404, но логика работы сервиса выдает пустой экран или некорректные данные, наступает этап отладки. Проанализируем, как подключить отладчик конфигуратора к HTTP-запросам:

Запустите сервер приложений 1С с ключом отладки. Для этого в параметрах запуска службы должно быть прописано: -debug -http.
Откройте конфигуратор вашей информационной базы.
Перейдите в меню Отладка -> Подключение...
В открывшемся окне "Доступные локальные предметы" найдите строку с типом подключения "HTTP-сервис" или "Внешнее соединение" и нажмите кнопку Подключить.
Установите точку останова непосредственно внутри программного модуля вашего HTTP-сервиса (например, в начале функции-обработчика метода POST).
Отправьте запрос из Postman. Выполнение кода прервется в конфигураторе, и вы сможете детально исследовать объект Запрос, его заголовки и тело.

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

← На главную