Почему возникает ошибка "Не указан заголовок управления сеансами" при тестировании HTTP-сервиса 1С в Postman и как ее исправить?

При разработке и интеграции HTTP-сервисов на платформе 1С программисты часто используют популярный инструмент Postman для тестирования запросов. Однако в процессе тестирования можно столкнуться с неожиданными ошибками. Разберем типичную ситуацию: вы создали простой метод, который должен возвращать статус 200, например, используя следующий код:

Ответ = Новый HTTPСервисОтвет(200);
Возврат Ответ;

Но при отправке GET-запроса через Postman сервер 1С возвращает ошибку с кодом 400 и сообщением: "Не указан заголовок управления сеансами или куки с идентификатором сеанса". Если же попытаться сбросить сеансы на сервере 1С, ошибка может смениться на код 404: "Сеанс отсутствует или удален" (с указанием SeanceContextException). Проанализируем, почему это происходит и как правильно настроить взаимодействие 1С и Postman.

Как 1С управляет сеансами HTTP-сервисов

Подобные ошибки напрямую связаны с настройками самого HTTP-сервиса в конфигураторе 1С. Обратим внимание на свойство сервиса, которое называется "Повторное использование сеансов". Рассмотрим подробнее три доступных режима работы этого свойства:

1. Не использовать. В этом режиме на каждый входящий HTTP-запрос платформа создает абсолютно новый сеанс. После формирования и отправки ответа клиенту этот сеанс сразу же уничтожается. Такой подход гарантирует изоляцию запросов, но является очень ресурсоемким, так как создание сеанса требует времени и памяти сервера.
2. Использовать автоматически. При выборе этой настройки платформа 1С берет управление сеансами на себя. Она создает и поддерживает пул готовых рабочих сеансов. Когда поступает новый запрос, 1С выдает для него свободный сеанс из пула, а после выполнения возвращает обратно. От клиента (в нашем случае Postman) при этом не требуется передавать никаких дополнительных заголовков или куки.
3. Использовать. Этот режим подразумевает ручное управление сеансом со стороны клиента, обращающегося к сервису. В данном случае клиент обязан самостоятельно передавать специальный HTTP-заголовок IBSession (со значениями start, finish или идентификатором сессии), либо серверные куки (например, ibsession). Если в 1С установлен этот режим, но клиент не передал нужные данные авторизации сеанса, 1С закономерно прерывает запрос и возвращает ту самую 400 ошибку о неуказанном заголовке.

Почему Postman начинает выдавать ошибку "Сеанс отсутствует или удален"?

Выясним причину второй ошибки, которая возникает после перезапуска сервера или ручного сброса сеансов в консоли администрирования 1С. Дело в том, что Postman по умолчанию ведет себя как обычный веб-браузер. Когда 1С при первом успешном запросе отдает куки (cookie) с идентификатором сеанса, Postman заботливо сохраняет их в своей внутренней памяти.

При всех последующих запросах к этому же IP-адресу или домену Postman будет автоматически подставлять сохраненные куки в заголовки запроса. Если сеанс на стороне 1С по какой-то причине перестал существовать (истек таймаут, вы удалили его вручную, перезапустилась служба сервера 1С или веб-сервер Apache/IIS), Postman ничего об этом не знает. Он отправляет идентификатор уже "мертвого" сеанса. Платформа 1С считывает этот ID, пытается найти соответствующий сеанс в оперативной памяти и, не находя его, выдает 404 ошибку: "Сеанс работы завершен администратором. Сеанс отсутствует или удален".

Решение проблемы по шагам

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

Способ 1: Настройка Postman (для тестирования "чистых" запросов)

Если вам нужно, чтобы каждый запрос из Postman обрабатывался как независимый (stateless), необходимо запретить ему отправлять старые куки. Сделаем следующее:

1. Откройте вкладку с вашим запросом в Postman.
2. Перейдите в раздел Settings (Настройки) конкретного запроса.
3. Найдите и включите тумблер Disable cookie jar (Отключить хранилище куки-файлов).

Теперь Postman перестанет сохранять и отправлять устаревшие идентификаторы сессий 1С, и ошибка с удаленным сеансом больше не появится.

Способ 2: Правильная настройка HTTP-сервиса в 1С (рекомендуется)

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

1. Откройте конфигуратор 1С и найдите ваш HTTP-сервис.
2. Откройте его свойства.
3. Найдите свойство ПовторноеИспользованиеСеансов.
4. Установите значение "Использовать автоматически".
5. Обновите конфигурацию базы данных и при необходимости перезапустите веб-сервер.

Установка автоматического режима даст высокую производительность благодаря использованию пула сеансов платформой. При этом она полностью избавит сторонних разработчиков и внешние системы от необходимости реализовывать сложную обработку куки или вручную передавать заголовки IBSession. Сервис будет работать стабильно и отвечать статусом 200 на корректные вызовы. При необходимости тестирования сервисов без внешних клиентов можно использовать инструмент для отладки REST API в 1С.