Как проверить публикацию HTTP-сервиса 1С

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

Типовая схема такова: в конфигураторе создан объект «HTTP-сервис» с шаблоном URL и методом, база опубликована на IIS или Apache с включённой опцией «Публиковать HTTP-сервисы», а внешняя система обращается по адресу вида http://server/base/hs/orders/get. Сбой на любом этапе даёт характерные симптомы — от ошибки 404 до таймаута.

Ниже разобран практический порядок диагностики: от проверки настроек публикации до анализа ответа сервера. Материал применим к платформе 8.3 на Windows (IIS) и Linux/Windows (Apache), для файловых и клиент-серверных баз.

Убедитесь, что HTTP-сервис и публикация настроены правильно

Первый шаг — проверить сам объект в конфигураторе. Откройте ветку «Общие → HTTP-сервисы», найдите нужный сервис и убедитесь, что у него задан корневой URL (свойство «Корневой URL», например api), есть хотя бы один шаблон URL и у шаблона определён HTTP-метод (GET, POST и т.д.) с назначенным обработчиком. Если обработчик не назначен, сервис формально существует, но отвечать не будет.

Далее проверьте настройки публикации. Откройте «Администрирование → Публикация на веб-сервере» и убедитесь, что на вкладке «HTTP-сервисы» стоит флаг «Публиковать HTTP-сервисы» и в списке отмечен нужный сервис. Частая ситуация: база опубликована давно, а сервис добавили позже — после добавления сервиса публикацию нужно обновить (перепубликовать), иначе в файле настроек его не будет.

Проверьте файл публикации default.vrd

При публикации платформа формирует в каталоге публикации файл default.vrd — именно его читает модуль веб-сервера, чтобы понять, какие HTTP-сервисы обрабатывать и к какой базе подключаться. Найдите каталог публикации (для IIS это путь, указанный при публикации; для Apache — каталог, заданный в конфигурации виртуального хоста) и откройте файл в текстовом редакторе.

Внутри должен присутствовать блок <point name="ИмяСервиса"> с атрибутом alias, равным корневому URL сервиса. Если такого блока нет — публикация устарела, перепубликуйте базу. Также проверьте атрибуты подключения к базе: для клиент-серверного варианта это ib="Srvr=...;Ref=...;", для файлового — путь к каталогу базы. Ошибка в строке подключения приведёт к тому, что веб-сервер будет отвечать, но обращение к базе завершится ошибкой.

<point name="ExchangeService" alias="hs">
  <http:service name="ExchangeService"/>
</point>

Проверьте доступность сервиса тестовым запросом

Соберите полный URL по схеме: http://сервер/имя_публикации/hs/корневой_url/шаблон_url. Обратите внимание: сегмент hs платформа подставляет автоматически — это признак обращения именно к HTTP-сервису (в отличие от odata или веб-сервисов ws). Ошибка в одном сегменте пути — самая частая причина ответа 404.

Для GET-метода начните с простого запроса в браузере — этого достаточно, чтобы увидеть код ответа и тело. Для POST, PUT и методов с телом используйте Postman, Insomnia или curl. В curl базовая проверка выглядит так:

Расшифруйте код ответа сервера

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

При ответе 500 обязательно загляните в журнал регистрации базы («Администрирование → Журнал регистрации» в режиме предприятия) — туда платформа пишет текст исключения из обработчика. Параллельно проверьте логи веб-сервера: для IIS это файлы в C:\inetpub\logs\LogFiles, для Apache — access.log и error.log. Сопоставление времени запроса и записей в логах обычно сразу локализует проблему.

Проверьте права пользователя и аутентификацию

HTTP-сервисы в 1С выполняются от имени конкретного пользователя информационной базы. Если запрос приходит без аутентификации, платформа пытается использовать пользователя, указанного в default.vrd (параметры usr и pwd), либо анонимный доступ — и если он не настроен, возвращает 401.

Убедитесь, что у пользователя, под которым идёт обращение, есть право «Использование» на конкретный HTTP-сервис (настраивается в ролях, вкладка прав на объекты). Также проверьте, что пользователь не заблокирован и аутентификация 1С для него включена. Отдельный частый случай — на веб-сервере включена только анонимная аутентификация IIS, а заголовок Authorization не пробрасывается в 1С; тогда сервис видит пустого пользователя даже при корректных логине и пароле в запросе.

Отладьте код обработчика, если сервис отвечает, но неверно

Если сервис возвращает 200, но содержимое ответа не соответствует ожиданиям, проблема в логике обработчика. Включите отладку HTTP-сервисов: в конфигураторе откройте «Сервис → Параметры → Отладка» и убедитесь, что разрешена отладка по протоколу HTTP, затем запустите отладку с типом подключения, соответствующим веб-серверу. Поставьте точку останова в обработчике и отправьте запрос повторно — исполнение остановится в нужном месте.

На старте разработки полезен приём «эхо-ответа»: временно сделайте обработчик, который возвращает полученные заголовки, параметры и тело запроса. Это позволяет отделить проблемы транспорта (не дошёл параметр, обрезалось тело, неверный Content-Type) от проблем бизнес-логики. Также помните, что тело запроса читается методом ПолучитьТелоКакСтроку() один раз — повторное чтение даст пустую строку.

Проверьте результат и зафиксируйте контрольные точки

Финальная проверка — не разовый запрос, а подтверждение, что вся цепочка стабильна. Убедитесь, что сервис отвечает корректно при повторных вызовах, при передаче реальных данных внешней системы и после перезапуска веб-сервера (публикация не должна «слетать»). Для сервиса, доступного извне, дополнительно проверьте поведение при неверном пароле, отсутствующих параметрах и слишком большом теле запроса — обработчик должен возвращать осмысленные коды, а не падать с 500.

Если сервис работает в браузере, но не работает из внешней системы, сравните запросы побайтово: заголовки, Content-Type, кодировку тела. Различие почти всегда в том, что внешняя система шлёт не то, что браузер, — например, не передаёт заголовок авторизации или отправляет данные в другой кодировке.

Частые вопросы