What does a SOAP envelope contain, which of its parts are mandatory, and how does it tell a receiver which SOAP version it uses?
answer
- one root, at most two children
- one optional, one mandatory
- Header first, Body straight after
- no version number anywhere
- the Envelope's namespace URI decides
basics
~20 sA SOAP envelope is the root element: an optional Header of namespace-qualified header blocks, then a mandatory Body. The Envelope's namespace URI, not a version number, says SOAP 1.1 or 1.2; an unsupported one draws a VersionMismatch fault.
solid answer
~40 sEvery SOAP message is one `Envelope` element. Inside it comes an optional `Header`, which if present MUST be the first child, and then a mandatory `Body`. Each child of the Header is a header block (SOAP 1.1 calls it a header entry) and MUST be namespace-qualified; the Body carries the payload for the ultimate receiver, or a `Fault`. There is no version attribute: SOAP 1.1 puts the Envelope in `http://schemas.xmlsoap.org/soap/envelope/` and SOAP 1.2 in `http://www.w3.org/2003/05/soap-envelope`. A receiver that does not support the namespace it finds answers with a `VersionMismatch` fault, and a SOAP 1.2 node SHOULD add an `Upgrade` header block listing the envelopes it does accept. SOAP 1.2 also tightened the shape: nothing may follow the Body, which SOAP 1.1 had allowed.
code
xml · 11 lines<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<tx:TransactionContext xmlns:tx="http://example.org/tx"
env:mustUnderstand="true">tx-5001</tx:TransactionContext>
</env:Header>
<env:Body>
<o:GetOrderStatus xmlns:o="http://example.org/orders">
<o:OrderId>A-1042</o:OrderId>
</o:GetOrderStatus>
</env:Body>
</env:Envelope>go deeper
Recall the three elements, which one is optional, the order they must appear in, and that the Envelope's namespace URI distinguishes SOAP 1.1 from SOAP 1.2.
Explain what a receiver does with an unexpected envelope namespace in each version, including the VersionMismatch fault and SOAP 1.2's Upgrade header block with SupportedEnvelope entries.
Show how you would diagnose a partner call failing with VersionMismatch: read the namespace actually sent, establish which versions each side supports, and whether the endpoint can process both.
Weigh accepting both envelope versions at an integration edge against standardising on one, remembering that the versioning model covers only the envelope, not header blocks, encodings or bindings.
## What a SOAP message is A **SOAP message** is one XML document whose root element is the **`Envelope`**. Everything SOAP itself defines lives inside it: an optional **`Header`** for extensions and a mandatory **`Body`** for the payload. SOAP 1.1 is a W3C Note; SOAP 1.2 is a W3C Recommendation that redefines the message as an XML infoset rather than as one particular serialization, but the three-element shape is the same in both versions. ## The three elements | Element | Required? | Position | Holds | |---|---|---|---| | `Envelope` | yes | the document element | a `Header` (optional) and a `Body` | | `Header` | no | first child of `Envelope` when present | header blocks (SOAP 1.1: header entries) | | `Body` | yes | directly after `Header`, otherwise first child | the payload for the ultimate receiver, or a `Fault` | - **Header blocks** are how SOAP is extended without prior agreement between the parties: a transaction context, a security token, a correlation identifier. Each one is identified by its fully qualified name, the namespace URI plus the local name, so both versions require every immediate child of the Header to be namespace-qualified. - Header blocks may carry attributes that say **which node** should process them and **whether processing is mandatory**; those rules are the processing model, separate from the envelope's shape. - **Body children** are the application's message: a request, a response or a one-way document. SOAP 1.1 says they MAY be namespace-qualified; SOAP 1.2 says they SHOULD be. - The **`Fault`** is the one Body child SOAP defines itself; it reports an error in place of a normal result. ## Rules a receiver can rely on 1. The Header, if present, comes first and the Body follows it immediately; a Body before a Header is not a SOAP message. 2. SOAP 1.1 lets the Envelope carry extra namespace-qualified elements after the Body; SOAP 1.2 permits none, because its Envelope has exactly one or two children, Header and Body. 3. Neither version allows a document type declaration. SOAP 1.1 forbids processing instructions outright; SOAP 1.2 forbids an initial sender to include them, and a receiver that finds one SHOULD answer with a fault whose Code is `env:Sender`. 4. SOAP 1.1 allows the `encodingStyle` attribute on any element; SOAP 1.2 names the elements where it may appear, and the `Envelope` is not one of them. ## The namespace is the version There is no version number in a SOAP message. SOAP 1.1 says outright that it does not define a major/minor versioning model. The **XML namespace of the `Envelope` element** is the version signal: | Version | Envelope namespace | |---|---| | SOAP 1.1 | `http://schemas.xmlsoap.org/soap/envelope/` | | SOAP 1.2 | `http://www.w3.org/2003/05/soap-envelope` | Two elements with the same local name in different namespaces are simply different elements, so a processor knows which rule book applies before it reads anything else. SOAP 1.2's versioning model covers **only the Envelope**: it does not version header blocks, encodings or protocol bindings. A node MAY support several envelope versions, but it MUST process each message with the semantics of the version that message declares. ## What happens on a mismatch - **SOAP 1.1:** a receiver that finds the Envelope in any other namespace MUST treat it as a version error and discard the message; over a request/response protocol such as HTTP it MUST reply with a fault whose `faultcode` is `VersionMismatch`, using the SOAP 1.1 namespace. - **SOAP 1.2:** a node that does not support the message's version MUST generate a fault whose Code `Value` is `env:VersionMismatch`, and SHOULD include an **`Upgrade`** header block whose `SupportedEnvelope` children name, by `qname`, the envelopes it accepts, most preferred first. Any other malformation of the message construct is an `env:Sender` fault instead. - **Crossing versions:** the transition appendix of SOAP 1.2 Part 1 says a SOAP 1.1 node receiving a 1.2 message answers with a SOAP 1.1 VersionMismatch fault. A SOAP 1.2 node receiving a 1.1 message MAY process it as 1.1 if it supports that version; otherwise it MUST answer with a VersionMismatch fault built as a SOAP 1.1 message, which SHOULD carry an `Upgrade` block advertising SOAP 1.2, so the older sender can actually read the refusal. ## Why interviewers ask The question checks whether a candidate sees SOAP as a message format with rules rather than as "XML over HTTP". Knowing that the Header is optional and the Body is not, that header blocks must be namespace-qualified, and that the namespace rather than a version attribute decides which rules apply explains a classic first-day failure with a new partner: a client built for one version calls an endpoint that speaks only the other and gets a VersionMismatch fault back. How each version is labelled on the wire, through the media type and the action, is the transport binding's business and sits on top of the envelope rather than inside it.
- Is a SOAP message with an empty Body valid?Yes. Both versions require the `Body` element itself but allow it to have no children: SOAP 1.1 says it MAY contain body entries, and SOAP 1.2 allows zero or more child elements. What an empty Body means is up to the application contract, not to SOAP.
- Why does SOAP signal its version with a namespace instead of a version attribute?Because the namespace changes the element's identity: a SOAP 1.2 `Envelope` and a SOAP 1.1 `Envelope` are different expanded names, so a processor recognises the version from the root element before interpreting anything. SOAP 1.1 explicitly declines a major/minor numbering model, and SOAP 1.2's versioning model is directed only at the Envelope element.
- What can a SOAP 1.2 node add to a VersionMismatch fault to help the sender recover?An `Upgrade` header block containing one or more `SupportedEnvelope` elements, each with a `qname` attribute naming an envelope it understands, ordered from most to least preferred. When the offending message was SOAP 1.1, the fault itself is built as a SOAP 1.1 message so the sender can parse it.
saying these in an interview costs you the question
- Every SOAP message must contain a Header, even an empty one.
- The SOAP version is carried in a version attribute on the Envelope.
- Header blocks can be plain elements with no namespace.
- The Body may come before the Header when both are present.
- SOAP 1.2 still allows extra elements after the Body.