SOAP Header
SOAP Header — это элемент структуры SOAP-сообщения (Simple Object Access Protocol), который содержит метаданные, необходимые для обработки запроса или ответа. Он является необязательной частью конверта SOAP (SOAP Envelope) и располагается после обязательного элемента SOAP Body. Основная функция заголовка — передача контекстной информации, не относящейся непосредственно к данным вызова, но влияющей на их обработку: маршрутизация, аутентификация, транзакции, шифрование, управление сессиями.
Структура и синтаксис
SOAP Header представляет собой XML-элемент <Header>, который является прямым дочерним элементом корневого элемента <Envelope>. Внутри <Header> могут размещаться произвольные XML-элементы, определённые разработчиком или стандартными спецификациями (например, WS-Security, WS-Addressing). Каждый такой элемент называется заголовочным блоком (header block).
Пример минимальной структуры SOAP-сообщения с заголовком:
``xml <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">; <soap:Header> <auth:Authentication xmlns:auth="http://example.com/auth">; <auth:Username>user1</auth:Username> <auth:Password>secret</auth:Password> </auth:Authentication> </soap:Header> <soap:Body> <getData xmlns="http://example.com/data">; <id>123</id> </getData> </soap:Body> </soap:Envelope> ``
Каждый заголовочный блок может содержать атрибуты, управляющие его обработкой:
actor(илиroleв SOAP 1.2) — указывает, какой узел (SOAP-посредник или конечный получатель) должен обработать данный блок. Значение по умолчанию —http://schemas.xmlsoap.org/soap/actor/next` (все узлы на пути сообщения).mustUnderstand— логический атрибут (true/falseили1/0). Если установлен вtrue, получатель обязан обработать данный блок, иначе вернуть ошибкуSOAP Faultс кодомMustUnderstand.encodingStyle— определяет схему кодирования данных в блоке (рекомендуется использовать только в теле, в заголовке применяется редко).
Назначение и типичные применения
### Аутентификация и авторизация
Заголовок часто используется для передачи учётных данных: логин/пароль, токены, сертификаты. Стандарт WS-Security (Web Services Security) определяет специальные заголовочные блоки для подписей и шифрования, что позволяет обеспечить целостность и конфиденциальность сообщения на уровне протокола.
### Маршрутизация и посредники
В распределённых системах SOAP-сообщение может проходить через несколько промежуточных узлов (SOAP-посредников). Заголовок позволяет указать, какие узлы должны обработать сообщение, а какие — просто передать дальше. Пример — стандарт WS-Addressing, который добавляет заголовки для указания адреса отправителя, получателя, обратного адреса и идентификатора сообщения.
### Управление транзакциями
Спецификация WS-AtomicTransaction использует заголовки для координации распределённых транзакций. Заголовок может содержать идентификатор транзакции, состояние участника и инструкции по завершению (commit/rollback).
### Сессионная информация
Заголовок может передавать идентификатор сессии (session ID) или куки, что позволяет серверу сохранять состояние между запросами клиента.
### Кэширование и управление временем жизни
Заголовок может содержать метки времени, срок действия сообщения или указания на необходимость кэширования ответа на промежуточных узлах.
Правила обработки
Согласно спецификации SOAP 1.1 и 1.2, обработка заголовка подчиняется следующим правилам:
- Необязательность: Клиент может не включать
<Header>в сообщение. Если заголовок отсутствует, сообщение считается корректным. - Порядок блоков: Порядок следования заголовочных блоков не определён стандартом, однако некоторые реализации требуют определённого порядка для корректной обработки (например, сначала блоки аутентификации, потом — маршрутизации).
- Обработка атрибута
mustUnderstand: Если получатель не может обработать блок сmustUnderstand="true", он должен сгенерировать ошибкуSOAP Faultс кодомMustUnderstand. Это предотвращает игнорирование критически важных данных. - Промежуточные узлы: Узел, не являющийся конечным получателем, может удалить или модифицировать заголовочные блоки, если это указано в его роли. Однако блоки с
mustUnderstand="true"должны быть обработаны каждым узлом, для которого предназначен данный блок. - Пространства имён: Каждый заголовочный блок должен быть квалифицирован пространством имён (xmlns), чтобы избежать конфликтов имён между разными расширениями.
Различия между SOAP 1.1 и SOAP 1.2
В SOAP 1.2 атрибут actor заменён на role, а также введены новые значения для ролей:
http://www.w3.org/2003/05/soap-envelope/role/nextactor="next"` (все узлы).— аналогhttp://www.w3.org/2003/05/soap-envelope/role/none` — блок не должен обрабатываться ни одним узлом (используется для хранения данных, не предназначенных для обработки).http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver` — только конечный получатель.
Кроме того, в SOAP 1.2 атрибут mustUnderstand может принимать значения true или false (без числовых эквивалентов), а также введён атрибут relay (если true, промежуточный узел может передать блок дальше, даже если не обработал его).
Примеры использования
### Аутентификация через WS-Security
``xml <soap:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">; <wsse:UsernameToken> <wsse:Username>admin</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">base64hash</wsse:Password>; </wsse:UsernameToken> </wsse:Security> </soap:Header> ``
### Маршрутизация через WS-Addressing
``xml <soap:Header> <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing">uuid:123456</wsa:MessageID>; <wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/08/addressing">; <wsa:Address>http://client.example.com/response</wsa:Address>; </wsa:ReplyTo> <wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing">http://service.example.com/endpoint</wsa:To>; <wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing">http://example.com/action/getData</wsa:Action>; </soap:Header> ``
Критика и ограничения
Основные недостатки SOAP Header связаны с его сложностью и избыточностью:
- Увеличение размера сообщения: XML-разметка заголовков может значительно увеличивать объём передаваемых данных, особенно при использовании множества расширений (WS-Security, WS-Addressing).
- Сложность отладки: Ошибки в заголовках (например, неправильное пространство имён или отсутствие обязательного блока) часто приводят к трудно диагностируемым ошибкам
SOAP Fault. - Низкая производительность: Обработка заголовков требует дополнительных вычислительных ресурсов, особенно при проверке подписей и шифровании.
- Отсутствие стандартизации для многих сценариев: Хотя существуют стандарты (WS-*), многие компании используют собственные проприетарные заголовки, что снижает интероперабельность.
В современных веб-сервисах, особенно в RESTful API, SOAP-заголовки используются реже из-за громоздкости и предпочтения более лёгких форматов (JSON, HTTP-заголовки, JWT-токены). Однако в корпоративных системах, где требуется строгая безопасность, транзакционность и маршрутизация, SOAP Header остаётся востребованным.
Источники
- W3C. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). 2007.
- W3C. SOAP Version 1.1. 2000.
- OASIS. Web Services Security: SOAP Message Security 1.1. 2006.
- W3C. Web Services Addressing 1.0 - Core. 2006.
- Box, D., Ehnebuske, D., Kakivaya, G., et al. Simple Object Access Protocol (SOAP) 1.1. W3C Note, 2000.
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →