HTTP-сервис 1С не отвечает или отвечает не то: проверка от публикации до кода

Проверить работу HTTP-сервиса в 1С проще всего одним запросом из командной строки: curl -v -u Логин:Пароль http://сервер/база/hs/корневойURL/шаблон. Код ответа сразу показывает, где проблема: 404 — сервис не опубликован или адрес собран неверно, 401 — не прошла аутентификация, 500 — ошибка в коде обработчика, 200 — сервис работает, остаётся проверить тело ответа.

Дальше выбор инструмента зависит от того, что сломалось. Публикацию и права проверяют через Конфигуратор и файл default.vrd. Логику обработчика — отладчиком и журналом регистрации. Таймауты — логами веб-сервера и замером времени на стороне клиента. Всё это работает на платформе 8.3.5 и новее: именно в ней появились HTTP-сервисы.

Из чего складывается адрес HTTP-сервиса

Половина «неработающих» сервисов на деле работает — запрос просто уходит не туда. Адрес собирается из четырёх частей, и каждую стоит сверить с конфигурацией.

Итого: http://srv/buh/hs/api/orders/125.

Где посмотреть параметры в Конфигураторе:

1. Откройте ветку Общие → HTTP-сервисы в дереве конфигурации.
2. В свойствах сервиса найдите «Корневой URL».
3. Раскройте сервис: под ним лежат шаблоны URL, под каждым шаблоном — методы (GET, POST и т. д.).
4. Двойным щелчком по методу откройте его свойства и проверьте, указана ли процедура-обработчик.

Типичные промахи на этом шаге:

• 🔤 регистр — путь в адресе чувствителен к нему, /API и /api для веб-сервера могут оказаться разными адресами;
• 🧩 параметр шаблона {id} в фигурных скобках подставляется значением, скобки в запрос писать не нужно;
• 🚫 метода нет в шаблоне — POST на шаблон, где описан только GET, обработан не будет;
• 📝 обработчик не назначен — метод описан, а функция в модуле сервиса не создана.

Публикация на веб-сервере и права пользователя

HTTP-сервис отвечает только через веб-сервер (IIS или Apache) с установленным модулем расширения веб-сервера из дистрибутива платформы.

Проверка публикации

В Конфигураторе откройте Администрирование → Публикация на веб-сервере. В окне публикации:

1. Проверьте имя публикации и каталог — они должны совпадать с адресом из запроса.
2. Включите «Публиковать HTTP-сервисы по умолчанию» или отметьте нужный сервис на вкладке HTTP-сервисов.
3. Нажмите «Опубликовать» и согласитесь на перезапуск веб-сервера.

Публикацию выполняйте с правами администратора Windows — иначе Конфигуратор не сможет записать файлы в каталог веб-сервера и настройки сервера.

После публикации в каталоге появится файл default.vrd. Убедитесь, что в нём есть раздел про HTTP-сервисы и сервисы не выключены:

<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/buh"
       ib="Srvr=&quot;srv1c&quot;;Ref=&quot;buh&quot;;">
  <httpServices publishByDefault="true"/>
</point>

Если publishByDefault="false", каждый сервис должен быть перечислен в httpServices отдельной строкой service с enable="true".

Модуль веб-сервера после обновления платформы

Частая причина внезапной ошибки 500 на всех запросах — обновили платформу, а веб-сервер продолжает загружать модуль старой версии или эту версию уже удалили.

• 🔎 Apache: в httpd.conf найдите строку LoadModule _1cws_module и проверьте путь к wsap24.dll — номер версии в пути должен совпадать с установленной платформой.
• 🔎 IIS: проверьте обработчик в настройках виртуального каталога, путь к wsisapi.dll и разрядность пула приложений.
• ⚙️ Разрядность модуля веб-сервера должна совпадать с разрядностью веб-сервера: 64-битный Apache не загрузит 32-битный модуль.

Права пользователя

Сервис выполняется от имени пользователя информационной базы. Проверьте:

• 👤 пользователь существует, у него включена аутентификация 1С:Предприятия и задан пароль;
• 🔑 логин и пароль в запросе передаются через Basic-аутентификацию, кириллический логин лучше заменить на латинский — клиенты по-разному кодируют такие строки;
• 🛡 у пользователя есть роли с правами на данные, которые читает и пишет обработчик. Нехватка прав проявится не как 401, а как исключение в коде и ответ 500.

Логин и пароль можно не передавать в каждом запросе, а указать в строке подключения публикации (Usr= и Pwd= в атрибуте ib). Тогда сервис доступен любому, кто знает адрес, а пароль хранится в файле открытым текстом. Такой вариант допустим только во внутренней сети и для служебного пользователя с минимальными правами.

Тестовый запрос: curl, Postman, браузер и сама 1С

Сначала убедитесь, что сервис отвечает вообще, и только потом разбирайтесь с данными.

Браузер

Подходит только для GET. Откройте адрес сервиса — браузер сам запросит логин и пароль. Удобно для первой проверки, но код ответа и заголовки придётся смотреть в инструментах разработчика (F12, вкладка «Сеть»).

curl

Есть в Windows 10, Windows Server 2019 и новее, а также в любом Linux. Ключ -v показывает заголовки запроса и ответа:

curl -v -u Service:Pass123 "http://srv/buh/hs/api/orders/125"

curl -v -u Service:Pass123 -X POST ^
  -H "Content-Type: application/json; charset=utf-8" ^
  -d "{\"number\":\"A-17\",\"sum\":1500}" ^
  "http://srv/buh/hs/api/orders"

В PowerShell вместо curl вызывайте curl.exe: в старых версиях PowerShell слово curl — псевдоним другой команды с иными параметрами.

Postman и аналоги

Удобны, когда запросов много: сохраняют коллекции, переменные окружения и историю. На вкладке авторизации выберите Basic Auth, тело для POST задайте в формате raw → JSON. Время ответа Postman показывает рядом с кодом — пригодится при поиске медленных мест.

Запрос из другой базы 1С

Так проверяют сервис в тех же условиях, в которых его будет вызывать боевой клиент:

Соединение = Новый HTTPСоединение("srv", 80, "Service", "Pass123", , 30);
Запрос = Новый HTTPЗапрос("/buh/hs/api/orders/125");
Ответ = Соединение.ВызватьHTTPМетод("GET", Запрос);

Сообщить("Код: " + Формат(Ответ.КодСостояния, "ЧГ=0"));
Сообщить(Ответ.ПолучитьТелоКакСтроку());

Шестой параметр HTTPСоединение — таймаут в секундах. Для HTTPS добавьте объект ЗащищенноеСоединениеOpenSSL седьмым параметром и порт 443.

Как отладить обработчик HTTP-сервиса

Когда сервис отвечает 500 или возвращает не те данные, ставьте точку останова прямо в модуле сервиса.

Что нужно включить

1. Отладку в публикации. В default.vrd добавляется элемент debug с адресом сервера отладки. В окне публикации Конфигуратора для этого есть флажок разрешения отладки.
2. Отладку по протоколу HTTP в самом Конфигураторе: Сервис → Параметры → Отладка. Для клиент-серверной базы сервер 1С должен быть запущен с ключом -debug.
3. Автоматическое подключение: в Конфигураторе откройте Отладка → Подключение, нажмите «Автоматическое подключение» и отметьте сеансы HTTP-сервисов.

Пример строки в default.vrd:

<debug enable="true" protocol="http" url="http://srv:1550"/>

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

Порядок отладки

1. Поставьте точку останова в первой строке функции-обработчика.
2. Отправьте запрос из curl или Postman.
3. Конфигуратор остановится на точке, клиент в это время ждёт ответа.
4. В табло проверьте Запрос.HTTPМетод, Запрос.ПараметрыURL, Запрос.ПараметрыЗапроса и результат Запрос.ПолучитьТелоКакСтроку().

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

Журнал регистрации, техжурнал и логи веб-сервера

На рабочей базе отладчик обычно недоступен. Остаются логи — и их надо подготовить заранее.

Журнал регистрации

Ошибки HTTP-сервиса без явной записи в журнал теряются: клиент видит 500, а в журнале может не оказаться понятной причины. Записывайте её сами:

ЗаписьЖурналаРегистрации("HTTPСервис.Заказы",
    УровеньЖурналаРегистрации.Ошибка, , ,
    ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));

Журнал открывают в пользовательском режиме через Администрирование → Обслуживание → Журнал регистрации (в БП 3.0, ЗУП 3.1, УТ 11) или в Конфигураторе: Администрирование → Журнал регистрации. Отбор по имени события «HTTPСервис.Заказы» сразу оставит только ваши записи. Фильтр по пользователю помогает, когда сервис работает от служебной учётной записи.

Технологический журнал

Нужен, когда ошибка не доходит до кода: падение рабочего процесса, проблемы с лицензией, блокировки. Включается файлом logcfg.xml в каталоге conf платформы. Для начала достаточно событий EXCP (исключения) и CALL (вызовы с длительностью).

Логи веб-сервера

Здесь видно, дошёл ли запрос до веб-сервера вообще, с каким кодом он завершился и сколько длился.

• 📁 IIS: C:\inetpub\logs\LogFiles, по подкаталогу на сайт;
• 📁 Apache: access.log и error.log в каталоге logs установки.

Если в логе веб-сервера запроса нет — проблема в сети, DNS, прокси или брандмауэре, а не в 1С.

Исключения и корректный ответ сервиса

Хороший сервис сам объясняет клиенту, что не так. Тогда половину проверок можно сделать по ответу, не залезая в журнал.

Правила, которые экономят время при разборе:

• 🧱 оборачивайте тело обработчика в Попытка … Исключение и не отдавайте 500 без текста;
• 🔢 для ошибок клиента возвращайте 400 (неверные данные) или 404 (объект не найден), для своих — 500;
• 🏷 задавайте Content-Type с charset=utf-8 и пишите тело в UTF-8;
• 🙈 не возвращайте наружу полный стек ошибки — он раскрывает устройство базы; подробности пишите в журнал.

Пример обработчика GET с проверкой параметра и записью ошибки:

Функция ЗаказыGET(Запрос)

    Попытка
        Номер = Запрос.ПараметрыURL.Получить("id");
        Если Не ЗначениеЗаполнено(Номер) Тогда
            Возврат ОтветJSON(400, "Не указан номер заказа");
        КонецЕсли;

        // ... поиск заказа и формирование данных
        Возврат ОтветJSON(200, "Заказ " + Номер + " найден");

    Исключение
        ЗаписьЖурналаРегистрации("HTTPСервис.Заказы",
            УровеньЖурналаРегистрации.Ошибка, , ,
            ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
        Возврат ОтветJSON(500, "Внутренняя ошибка, подробности в журнале");
    КонецПопытки;

КонецФункции

Функция ОтветJSON(Код, Текст)

    Запись = Новый ЗаписьJSON;
    Запись.УстановитьСтроку();
    ЗаписатьJSON(Запись, Новый Структура("message", Текст));

    Ответ = Новый HTTPСервисОтвет(Код);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    Ответ.УстановитьТелоИзСтроки(Запись.Закрыть(), КодировкаТекста.UTF8);
    Возврат Ответ;

КонецФункции

Обработчик обязан вернуть объект HTTPСервисОтвет на любом пути выполнения. Ветка, которая заканчивается без Возврат, — классическая причина ошибки на редких входных данных.

Таймауты и медленные ответы

Если сервис отвечает, но долго или обрывается по таймауту, сначала выясните, где теряется время.

Если время обработчика маленькое, а полное — большое, ищите задержку в сети, на веб-сервере или в создании сеанса.

Что обычно помогает:

1. Таймаут клиента. У HTTPСоединение он задаётся параметром в секундах; значение 0 означает отсутствие ограничения, что опасно — клиент может зависнуть навсегда.
2. Таймауты веб-сервера. У Apache — директива Timeout, у IIS — ограничения сайта и пула приложений. Если обработчик работает дольше, веб-сервер разорвёт соединение раньше 1С.
3. Повторное использование сеансов. Каждый вызов по умолчанию открывает новый сеанс 1С, а это заметные доли секунды. В default.vrd для сервиса можно задать атрибут reuseSessions — тогда сеансы берутся из пула.
4. Долгие операции — в фон. Если обработка занимает минуты, принимайте запрос, запускайте фоновое задание, сразу возвращайте 202 и номер задания, а результат отдавайте отдельным GET.
5. Блокировки. Сервис, который записывает документы параллельно с пользователями, ждёт освобождения блокировок. Таймаут на блокировке виден в журнале регистрации и техжурнале как отдельное исключение.

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