Common WWSAPI errors: SOAP version mismatch

There are two versions of SOAP supported by WWSAPI and most other web services stacks: SOAP 1.1 and SOAP 1.2. Although the basic message layout in the two SOAP versions is the same (Header and Body inside Envelope), there are three main differences: the namespace, the content type for HTTP binding and the SOAP fault layout. Since the HTTP content type header is typically the first thing a receiver checks, the error message for SOAP version mismatch often refers to content type instead of namespace. When a WWSAPI client using the default SOAP version (1.2) communicates with a WCF endpoint using BasicHttpBinding (SOAP 1.1), you will see the following error messages in the client side trace or in the WS_ERROR object if you use it:

There was an error communicating with the endpoint at 'https://localhost:8000/CalculatorService/'.

The server returned HTTP status code '415 (0x19F)' with text 'Cannot process the message because the content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8'.'.

The format of the HTTP request was not supported by the server.

 

The actual WWSAPI error code returned is WS_E_INVALID_FORMAT (0x803d0000), which typically means that certain contract (API contract, network protocol contract, etc.) is not followed. In this case, 415 status code is returned when the client is expecting a 200/202/500 status code. Since WS_E_INVALID_FORMAT can be returned in many error cases, you probably need to turn on WWSAPI tracing or look at the error strings in the WS_ERROR object in order to figure out the exact cause. From the second error string above, you can tell that the error is due to SOAP version mismatch since SOAP 1.2 uses content type application/soap+xml, whereas SOAP 1.1 uses content type text/xml.

To fix this error, you’ll need to set the channel properties on the WWSAPI client to use the right SOAP version (as well as the right WS-Addressing version) as described in my previous post.