При интеграции систем «1С:Предприятие» с внешними веб-сервисами разработчики часто сталкиваются со странным поведением: внешний клиент (например, Postman, мобильное приложение или сторонний сайт) отправляет полноценный POST-запрос с телом в формате JSON, однако в базу 1С этот запрос «прилетает» как GET, а тело запроса (body) бесследно исчезает. При этом аналогичный запрос в рабочей базе может отрабатывать абсолютно корректно.
В этой статье мы подробно разберем, почему происходит такая подмена HTTP-методов, как функционируют механизмы перенаправления веб-серверов и какие шаги необходимо предпринять, чтобы восстановить корректную работу интеграции.
Давайте проанализируем физику процесса. В 99% случаев проблема кроется не в платформе 1С и не в кодовой базе вашего HTTP-сервиса. Виновником является веб-сервер (IIS, Apache или Nginx), который выполняет перенаправление (редирект) входящего запроса, а также логика работы HTTP-клиента, обрабатывающего этот редирект.
Схема выглядит следующим образом:
POST на определенный URL-адрес.301 Moved Permanently (Перемещено навсегда) или 302 Found (Найдено). В заголовке ответа Location сервер указывает новый «правильный» URL.Location. Однако, согласно исторически сложившейся спецификации HTTP (RFC 2616), при обработке редиректов 301 и 302 большинство клиентов принудительно изменяют метод запроса на безопасный GET и полностью отбрасывают тело запроса (JSON-данные).В результате до кода 1С доходит уже совершенно другой запрос — пустой GET, вызывающий ошибки обработки или возвращающий не те данные.
Выясним, какие именно настройки инфраструктуры заставляют веб-сервер инициировать перенаправление.
1. Отсутствие завершающего слэша (Trailing Slash) в URL
Это самая распространенная ошибка. Если в настройках публикации 1С адрес вашего сервиса выглядит как https://server/base/hs/my_service/, а в программе-клиенте вы отправляете запрос на https://server/base/hs/my_service (без косой черты на конце), веб-сервер (особенно часто этим «грешит» Apache с включенной директивой DirectorySlash) автоматически добавит слэш в конец адреса и вернет редирект 301. Клиент перейдет по адресу со слэшем, но уже методом GET.
2. Принудительный переход с HTTP на HTTPS (SSL/TLS)
На тестовом сервере или в локальной среде разработчики часто используют незащищенное соединение http://.... Но если на сервере настроено глобальное правило перенаправления всего трафика на защищенный протокол https://..., то при отправке запроса на HTTP-адрес сервер вернет редирект на HTTPS-версию сайта. Клиент выполнит повторный запрос на защищенный адрес, трансформировав POST в GET.
3. Различия в файлах конфигурации веб-сервера
При переносе базы из рабочей среды в тестовую конфигурация публикации может отличаться. Например, правила перезаписи URL (URL Rewrite) в файле web.config для IIS или правила в файле .htaccess для Apache могут содержать жесткие инструкции редиректа для тестовых доменов.
Рассмотрим по шагам, как выявить редирект и определить истинный целевой адрес запроса.
Ctrl + Alt + C (или Cmd + Option + C на macOS). Отправьте ваш проблемный POST-запрос. В консоли вы наглядно увидите цепочку вызовов: первый запрос со статусом 301 или 302, а следом за ним — второй запрос со статусом 200, но уже методом GET.301/302. Перейдите на вкладку Headers полученного ответа и найдите строку Location. Значение этого заголовка — это именно тот точный URL-адрес, который ожидает сервер. Используйте его для отправки вашего POST-запроса.POST, сохраняя тело запроса.Иногда проблема кроется в некорректно обновившемся файле описания публикации 1С — default.vrd. При разворачивании тестовой базы из резервной копии (файла .dt) структура метаданных может конфликтовать со старыми настройками веб-сервера.
Проанализируем правильный алгоритм перепубликации HTTP-сервиса:
C:\inetpub\wwwroot\TestBase\ для IIS или соответствующую папку в Apache) и убедитесь, что файл default.vrd действительно удален. При необходимости удалите его вручную.World Wide Web Publishing Service для IIS или службу Apache2.4).Для понимания того, как выглядит корректная структура файла default.vrd для работы с HTTP-сервисами, посмотрим на пример ниже:
<?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="/test_base"
ib="Srvr="Server1C";Ref="test_base";">
<httpServices publishByDefault="false">
<service name="MyCustomService" alias="my_service" enable="true"/>
</httpServices>
</point>
Обратите внимание на параметр base. Любые обращения к вашим сервисам должны строиться строго на основе этого имени публикации (например, /test_base/hs/my_service/my_method/).
Чтобы исключить внутренние ошибки платформы, убедитесь, что ваш метод HTTP-сервиса в конфигураторе настроен правильно. У метода должно быть четко указано свойство HTTP-метод: POST, а в самом коде модуля правильно считывается тело запроса.
Посмотрим на пример шаблона обработчика POST-запроса в модуле HTTP-сервиса 1С:
Функция ШаблонЗапросаPOST(Запрос)
Ответ = Новый HTTPСервисResponse(200);
Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
// Проверяем, что запрос пришел именно методом POST
Если ВРег(Запрос.HTTPМетод) <> "POST" Тогда
Ответ.КодСостояния = 405; // Method Not Allowed
Ответ.УстановитьТелоИзСтроки("{""error"": ""Ожидается метод POST""}");
Возврат Ответ;
КонецЕсли;
Попытка
// Получаем тело запроса в виде строки JSON
СтрокаЗапроса = Запрос.ПолучитьТелоКакСтроку("UTF-8");
// Здесь выполняется парсинг JSON и бизнес-логика
// ЧтениеДетализации = Новый ЧтениеJSON; ...
Ответ.УстановитьТелоИзСтроки("{""status"": ""success"", ""message"": ""Данные обработаны""}");
Исключение
Ответ.КодСостояния = 500;
Ответ.УстановитьТелоИзСтроки("{""error"": ""Ошибка обработки данных""}");
КонецПопытки;
Возврат Ответ;
КонецФункции
Использование проверки Запрос.HTTPМетод в начале функции позволяет сразу локализовать проблему на стороне 1С и вернуть клиенту понятную ошибку, если веб-сервер все-таки исказил метод запроса.
Подводя итоги, при возникновении проблемы трансформации методов всегда проверяйте настройки сетевого пути в клиенте отправки запросов, добавляйте закрывающий слэш, используйте HTTPS по умолчанию и своевременно обновляйте файлы публикации веб-сервера.