SOAPless
Sign Up
Back to Blog
soap-errorsaspnetsoapactionxml

Server did not recognize the value of HTTP Header SOAPAction

SOAPless Team2 min read

This error usually means the service received your request, but the action metadata did not line up with the operation it was prepared to handle.

Server did not recognize the value of HTTP Header SOAPAction

You see it a lot with older ASP.NET SOAP services and vendor endpoints that still expect SOAP 1.1 semantics very literally.

What usually causes it

The most common causes are:

  • the SOAPAction header is missing
  • the SOAPAction value is present but wrong
  • the request body wraps the wrong operation
  • the endpoint expects SOAP 1.2 while you sent SOAP 1.1, or the reverse
  • you copied a sample from a different environment or binding

Why this error is easy to misread

People often treat it as "the server rejected my auth" or "the XML is broken." Sometimes that is adjacent to the real problem, but the first thing to verify is simpler:

Does the action in the HTTP metadata match the operation in the body and the binding in the WSDL?

For SOAP 1.1, that usually means checking the SOAPAction header itself. For SOAP 1.2, the action can move into the Content-Type: application/soap+xml header as an action parameter.

What to compare

When debugging, compare these four things side by side:

  1. the WSDL binding operation
  2. the endpoint URL you actually called
  3. the outgoing action value
  4. the body wrapper element

If one of them came from a different sample, a different environment, or a different port in the WSDL, this error is a likely outcome.

A common real-world pattern

This comes up constantly when teams hand-copy XML from SoapUI or an integration PDF into app code, then later swap the endpoint or library. The XML body may still look reasonable, but the action header no longer matches the contract the receiver registered.

That is why this error is a good example of SOAP complexity leaking across team boundaries. It is not hard to fix once. It is expensive when every downstream consumer has to rediscover it.

Where SOAPless helps

This is exactly the sort of detail you want to centralize.

Instead of letting each client or batch job manage SOAPAction and binding-level quirks, SOAPless keeps that contract-specific behavior in one place and exposes a cleaner REST JSON surface to downstream teams.

Back to Blog