При интеграции 1С с внешними API (например, когда выполняется запрос информации по кодам маркировки в ГИС МТ «Честный ЗНАК») разработчики часто сталкиваются с ситуацией, когда запрос, полностью скопированный из работающей утилиты (Postman, Insomnia), возвращает ошибку 503 или 400 при отправке непосредственно из кода 1С. Проанализируем основные причины этой проблемы и разберем способы их решения.
Одной из самых распространенных скрытых причин является различие в символах переноса строки. Стандарт multipart/form-data требует использования строго определенной последовательности CRLF (Возврат каретки + Перевод строки). Если вы только начинаете изучать нюансы протокола, рекомендуем пройти интерактивный курс для работы с HTTP-запросами, где детально разбираются подобные основы.
В 1С при формировании текстового тела запроса вручную часто используется Символы.ПС (LF), в то время как внешние инструменты автоматически подставляют правильные разделители. Если сервер ожидает \r\n, а получает только \n, он не сможет корректно определить границы boundary, что приведет к ошибке парсинга или таймауту шлюза. Рассмотрим правильный способ формирования разделителя:
РазделительСтрок = Символы.ВК + Символы.ПС; // CRLF
ТелоЗапроса = "--" + Граница + РазделительСтрок;
ТелоЗапроса = ТелоЗапроса + "Content-Disposition: form-data; name=""jsonFile""; filename=""data.json""" + РазделительСтрок;
При записи JSON-файла или формировании двоичных данных для передачи внутри multipart-запроса, платформа 1С может автоматически добавлять маркер BOM в начало потока данных. Многие современные веб-серверы и парсеры некорректно обрабатывают этот символ в теле JSON, что вызывает внутреннюю ошибку сервера. Чтобы гарантировать корректность структуры данных, можно использовать валидатор OpenApi-схем, который поможет проверить соответствие ваших пакетов стандартам.
Проанализируем ситуацию: если вы используете ЗаписьТекста, необходимо явно указывать кодировку без BOM. Посмотрим на пример кода:
// Неправильно (может добавить BOM)
Запись = Новый ЗаписьТекста(ПутьКФайлу, КодировкаТекста.UTF8);
// Правильно (UTF-8 без BOM)
Запись = Новый ЗаписьТекста(ПутьКФайлу, "UTF-8");
Если штатный объект HTTPСоединение не справляется (например, из-за специфических настроек прокси или проблем с TLS), стоит рассмотреть возможность использования COM-объекта WinHttp.WinHttpRequest.5.1. В случаях, когда требуется простой обмен данными между базами 1С и приложениями, использование системных библиотек Windows часто помогает обойти ограничения платформы.
WinHTTP = Новый COMОбъект("WinHttp.WinHttpRequest.5.1");
WinHTTP.Open("POST", URL, Ложь);
WinHTTP.SetRequestHeader("Content-Type", "multipart/form-data; boundary=" + Boundary);
WinHTTP.Send(ТелоДвоичныеДанные);
Результат = WinHTTP.ResponseText;
Выясним еще одну техническую особенность: при передаче больших объемов данных или использовании потоков 1С может автоматически добавлять заголовок Transfer-Encoding: chunked. Подобная ситуация часто встречается, когда настраивается обмен с сайтом через POST-запрос для создания документов или передачи файлов.
Чтобы избежать этой ошибки, старайтесь передавать тело запроса целиком как ДвоичныеДанные и принудительно устанавливать заголовок Content-Length, что заставит платформу отправить запрос одним пакетом без использования chunked-режима.
В контексте методов агрегации и реализации таких механизмов как разрешительный режим на кассах, важно помнить, что ошибка 503 может быть ложной и означать внутренний таймаут валидации. Убедитесь, что:
X-Signature содержит корректную отсоединенную подпись в формате Base64 без лишних переносов строк.dateDoc передано как число (Unix Timestamp в миллисекундах), а не как строка.boundary в конце тела запроса имеет два дефиса в конце: --X-INSOMNIA-BOUNDARY--.Если все параметры верны, но ошибка сохраняется только в 1С, попробуйте упростить запрос, заменив multipart/form-data на прямой application/json, если API это позволяет для данного метода.