SOAP 1.1 versus 1.2 and HTTP bindings

The two versions differ in namespace, content type and how faults travel over HTTP, and a client that guesses wrong gets an unhelpful error.

What actually differs

	SOAP 1.1	SOAP 1.2
Envelope namespace	`http://schemas.xmlsoap.org/soap/envelope/`	`http://www.w3.org/2003/05/soap-envelope`
Content-Type	`text/xml; charset=utf-8`	`application/soap+xml; charset=utf-8`
Action	`SOAPAction` HTTP header, quoted	Inside the content type as `action="..."`
Fault element name	`faultcode`, `faultstring` as children of `Fault`	`Code`, `Reason`, `Detail`
Fault over HTTP	500 for a fault, 200 for success	400 for a client fault, 500 for a server fault
HTTP GET binding	Not defined	Optional and rarely used
mustUnderstand	`1` or `0`	`true` or `1`
Encoding style	Section 5 encoding common	Encoding rules removed from the spec

POST /OrderService HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:example:orders/PlaceOrder"

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <PlaceOrder xmlns="urn:example:orders"><sku>A-1</sku><qty>2</qty></PlaceOrder>
  </soap:Body>
</soap:Envelope>

POST /OrderService HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8; action="urn:example:orders/PlaceOrder"

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Body>
    <PlaceOrder xmlns="urn:example:orders"><sku>A-1</sku><qty>2</qty></PlaceOrder>
  </env:Body>
</env:Envelope>

Detecting what a service expects

# Read the WSDL binding: soap:binding vs soap12:binding tells you the version
curl -s "https://example.com/OrderService?wsdl" | grep -E "soap1?2?:binding|soap12:"

# Inspect what the server actually sends back
curl -s -D - -o /dev/null -X POST "https://example.com/OrderService" \
  -H 'Content-Type: application/soap+xml; charset=utf-8; action="urn:example:orders/Ping"' \
  --data-binary @ping12.xml

# Order a 1.1 request with headers only, to see the error shape
curl -s -o - -D - -X POST "https://example.com/OrderService" \
  -H 'Content-Type: text/xml; charset=utf-8' \
  -H 'SOAPAction: "urn:example:orders/Ping"' \
  --data-binary @ping11.xml

A 1.2 client calling a 1.1 endpoint usually gets a 415 or a badly formed fault, because the server cannot parse the content type.
A 1.1 client calling a 1.2 endpoint may succeed if the envelope namespace is right, but a fault will use the wrong element names and crash the client's fault parser.
Many enterprise services expose both bindings from one WSDL and are otherwise identical.
If a service sends SOAPAction in the header of a 1.2 response, migration was incomplete — expect other 1.1 assumptions.

⚠️

A proxy that strips or rewrites SOAPAction, or that normalises the content type to text/xml, is a very common source of "works locally, fails through the gateway" tickets. Capture the request at the last hop before the service before you blame the client.

FAQ

Which version should a new service use?

SOAP 1.2, because it is the current standard and carries the action inside the content type, which survives proxies better than a custom header. Use 1.1 only to match an existing partner.

Is the SOAPAction value case sensitive?

Treat it as case sensitive and preserve the exact string from the WSDL. Some servers compare it strictly, and 1.1 requires it to be quoted even when empty.

What SOAP is and how the envelope works WSDL contracts and code generation

Last refreshed 2026-09-18.

SOAP 1.1 versus 1.2 and HTTP bindings

What actually differs

Detecting what a service expects

FAQ

Related