| Category | Issue |
| HTTP Header | Some implementations
support both SOAPAction values of "" and (null), while others do
not (the soap spec does differentiate between the two of these)
Some implementations do note quote their SOAPAction values at all for non-null SOAPAction values. |
| HTTP Header | Some implementations error if an incoming HTTP header shows a "charset" attribute on content-type, such as: text/xml; charset=UTF-8. Others always use the charset attribute going out, though they don't require it for incoming messages. |
| Message Parameters | Some toolkits have the ability to set multiple out params, while most toolkits can process one and only one out param |
| Message Parameters | Clients implementations must always be able to set parameter element names to values specified by the server, and receive element names specified by the server for return value. Some clients/server implementations rely on parameter order, not name, and thus hard-code or autogenerate parameter element names. |
| Message Parameters | Some implementations mandate strict conformance of array item element names to a specific pre-determined value (such as might be published in a WSDL file). Other implementations adhere to the soap specification that array item element names are unimportant and may take on any value. |
| SOAP Envelope | Some
implementations expect "encodingStyle" to be present for all
body elements (either explicitly or by inheritance) , since they assume
that the interchange is purely section 5 and use this as a safeguard from
trying to process messages that are not. Other implementations don't send
it, even if they ARE using section 5.
Some implementations cannot handle encodingStyle being defined anywhere except the top level envelope, whereas other implementations may place soapencoding on elements inside the envelope. |
| SOAP Envelope | While most implementations require namespace qualification of <Envelope> and <Body> , some implementations do not qualify one or both of these. |
| SOAP Envelope | Usually, body wrapper element namespace is set, while input and output parameter(s) are set to the "null" namespace. Some implementations do not follow this convention. |
| SOAP Envelope | At least one implementation has required that incoming soap envelopes include the XML declaration. Almost all implementations do not care whether it's there or not. |
| SOAP Envelope | Encoding - implementations differ on what XML encoding they use - none specified, UTF-8, etc. Usually, though, this is not a show stopper unless an implementation actually sends UTF-16, which I'm not sure I've ever seen. |
| SOAP Envelope | Some implementations send out the byte order mark, which others may not be able to handle. |
| SOAP Envelope | Some implementations send out values using IDs and HREFs, which others may not be able to handle. |
| Types / Encoding | At least one implementation uses SOAP-ENV as namespace prefix for arrayType ; according to spec, this should be SOAP-ENC |
| Types / Encoding | Some implementations require explicit typing of parameters by default. |
| Types / Encoding | In situations where the typing is explicit, there may be a mismatch on what types are supported (eg., "xsd:integer" vs "xsd:int" ) |
| Types / Encoding | Some implementations support SOAP-ENC:offset attribute for arrays, some do not. |
| Types / Encoding | Some implementations do not support arrays and simple structs. |
| WSDL | Some implementations explicitly require WSDL to bind to a server, while other implementations cannot provide WSDL documents automatically. |