Разработка HTTP-сервисов в расширениях — это удобный способ расширения функционала типовых конфигураций без изменения основной конфигурации. Однако процесс их публикации часто сопровождается трудностями: от банальных ошибок 404 (Not Found) до загадочных 400 (Bad Request) — для отладки таких сбоев пригодится инструмент логирования и анализа HTTP-запросов и ответов в 1С. В этой статье мы подробно разберем, как обеспечить стабильную работу вашего сервиса, проанализируем настройки веб-сервера и разберем нюансы конфигурации 1С.
Начнем с основ. При публикации информационной базы через конфигуратор (или используя удобный публикатор 1С) необходимо убедиться, что платформа «знает» о необходимости публиковать сервисы из расширений. Рассмотрим последовательность действий:
Если этот флаг не установлен, платформа просто проигнорирует ваш сервис при генерации файла настроек, и вы получите ошибку 404 при попытке обращения к нему.
Иногда графический интерфейс конфигуратора не вносит нужные изменения в файл настроек default.vrd. В таком случае нам придется проверить его содержимое вручную, что критично для правильной настройки и публикации Swagger. Этот файл обычно располагается в каталоге публикации на веб-сервере.
Проанализируем структуру секции <standardURLs>. Для того чтобы сервисы из расширений работали, в корневом теге или в секции расширений должен присутствовать атрибут publishByDefault="true". Пример корректной настройки:
<httpServices publishByDefault="true">
<service name="ВашСервис" rootUrl="my_service" />
</httpServices>
Если автоматическая публикация всех сервисов не подходит, мы можем использовать точечную настройку внутри тега <extensions>. Выясним причину, почему сервис может быть не виден: если в файле default.vrd отсутствуют упоминания о расширении, веб-сервер просто не направит запрос в нужный контекст 1С.
Одной из скрытых причин ошибок является использование кириллицы в именах метаданных. Рассмотрим ситуацию, когда сервис в конфигураторе назван на русском языке. Хотя платформа 1С поддерживает кириллические имена, веб-серверы (особенно Apache или старые версии IIS) могут некорректно обрабатывать такие URL.
Разберем рекомендации по именованию:
default.vrd атрибут service name содержит кириллицу, попробуйте заменить его значение на латинский эквивалент (соответствующий корневому URL).Часто проблема кроется не в публикации, а в правах доступа. При создании расширения платформа автоматически может создать роль, например, Расш1_ОсновнаяРоль. Если у вас несколько расширений и в каждом есть роль с одинаковым «синонимом» или похожим именем, это может привести к конфликту инициализации расширения.
Проанализируем поведение системы: если расширение не подключилось из-за ошибки в метаданных (например, дублирование имен ролей или некорректный режим совместимости), то и HTTP-сервис внутри него будет недоступен. Проверьте Журнал регистрации на наличие ошибок при старте сеанса веб-сервиса. Если вы видите сообщения о невозможности подключения расширения — проблему нужно искать в структуре ролей или свойствах самого расширения.
Ошибка 400 часто возникает не из-за неправильного адреса, а из-за проблем при инициализации HTTP-сеанса. Разберем механизм Повторного использования сеансов.
В свойствах HTTP-сервиса есть важный параметр — Повторное использование сеансов. Если он установлен в значение Использовать, платформа пытается оптимизировать работу, сохраняя сеанс открытым. Однако при определенных настройках веб-сервера (например, при использовании IIS в режиме Integrated Pipeline) это может приводить к ошибкам и «подвисанию» сеансов на сервере 1С.
Попробуем изменить это значение на Не использовать. Это заставит систему создавать новый сеанс для каждого запроса (или использовать пул сеансов веб-сервера более прозрачно). Как показывает практика, это часто устраняет ошибку HTTP/1.1 400 Bad request и предотвращает утечку сеансов, которые приходится завершать вручную через консоль сервера 1С.
Выясним, как правильно формируется адрес запроса. Стандартный путь к HTTP-сервису выглядит следующим образом:
http://<Сервер>/<ИмяБазы>/hs/<КорневойURLСервиса>/<ОтносительныйПутьШаблона>
Важно помнить:
/hs/ обязателен для всех HTTP-сервисов (и основных, и из расширений).Иногда даже при идеальных настройках в 1С сервис не работает. Проанализируем настройки веб-сервера:
Integrated на Classic. В некоторых случаях это решает проблемы взаимодействия с модулем расширения веб-сервера 1С.IUSR или NETWORK SERVICE), имеет права на чтение файлов в каталоге публикации и доступ к временным файлам платформы 1С.Для корректной работы сервисов в расширениях минимальная версия платформы должна быть 8.3.9, но крайне рекомендуется использовать 8.3.13 и выше. Проверьте свойство расширения Безопасный режим. Если ваш код внутри сервиса обращается к файловой системе или внешним компонентам, работа в безопасном режиме может блокировать эти действия, выдавая ошибку исполнения, которая на стороне клиента отобразится как 400 или 500.
Попробуем временно отключить Безопасный режим и Защиту от опасных действий в свойствах расширения, чтобы исключить влияние ограничений прав доступа на работоспособность сервиса.
Если вы получаете ошибку «Не указан заголовок управления сеансами», проверьте настройки отладки. Перейдите в настройки публикации, вкладка Прочее, и укажите Адрес отладчика (например, tcp://localhost). Это поможет системе правильно инициализировать контекст запроса, особенно если вы используете авторизацию или работаете в режиме разработки.
Рассмотренные шаги охватывают 99% проблем, связанных с публикацией HTTP-сервисов из расширений. Главное — последовательно проверять цепочку: Конфигурация (права/имена) -> Публикация (vrd-файл) -> Веб-сервер (права/перезапуск).