SOAP HTTP Binding

This document describes a binding for SOAP to HTTP/1.1, as described by RFC2616. HTTP defines two types of messages capable of carrying SOAP envelopes; request and response.

Encapsulating SOAP Envelopes in HTTP Request Messages

If a SOAP envelope is to be conveyed in the HTTP request, it should be the complete content of the message body, as defined by RFC2616, section 5, and use the 'POST' method (section 9.5).

If a SOAP envelope is not to be conveyed in the HTTP request, the request method used should be 'GET' (section 9.3).

Encapsulating SOAP Envelopes in HTTP Response Messages

If a SOAP envelope is to be conveyed in the HTTP response, it should be the complete content of the message body, as defined by RFC2616, section 6, with a '200 OK' status code (section 10.2.1).

If a SOAP envelope is not to be conveyed in the HTTP response, the response status code generated should be '204 No Content' (section 10.2.5).

Constraints Imposed

HTTP has both a fixed connection model and message exchange pattern; the client identifies the server through a URI, connects to it, issues a HTTP request message, and receives a HTTP response message. SOAP envelopes may or may not be encapsulated in either or both messages, as outlined above.

Services Available

HTTP always makes the following services available to SOAP applications:

• correlation - HTTP provides implicit corellation between its request and response messages; SOAP applications may choose to infer corellation between the SOAP envelope transfered by the HTTP request and the SOAP envelope returned with the associated HTTP response.
• endpoint identification - HTTP identifies the service endpoint, identifiable by a URI, as the server; HTTP request messages are sent to it, and HTTP responses are generated by it. HTTP requests are initiated by the client, and HTTP responses are sent to it. SOAP applications may use the service URI to identify the server, and assume the identity of the client through its role in HTTP's message exchange pattern.

Additionally, implementations may make the following available:

• authentication - The mechanism described in RFC2617 may be used to provide authentication from the client to the server.
• encryption - The SSL or TLS (RFC2246) protocols may be used in conjunction with HTTP to provide transport encryption. Additionally, it may provide authentication both from the client to the server and from the server to the client, with appropriate configuration.
• compression - HTTP message compression can be negotiated through either the Accept-Encoding/Content-Encoding mechanism, or the TE/Transfer-Encoding mechanism, as documented in RFC2616.
• message caching - The mechanisms described in section 13 of RFC2616 can be used to cache and reuse SOAP envelopes which are carried in HTTP responses.
• message integrity - The Content-MD5 HTTP header, as document in RFC2616 section 14.15, may be used as an integrity assurance mechanism (with the same caveats expressed therein).
• routing - HTTP requests are routed according to the authority portion of the request-URI; however, they may be routed to a HTTP intermediary if a local proxy is configured on the client. HTTP responses are routed as the correlated request was, in reverse.

Fault Destination

If a SOAP Fault message is generated by any node along the message path, it should be sent as the content of the HTTP response message body, by default.

Notes

HTTP implementations will time out if there is an unacceptable delay between the request and response messages; the exact timing is implementation-dependent. Additionally, HTTP intermediaries may transform messages as they pass through; use of the Cache-Control: no-transform (RFC2616, section 14.9.5) may or may not prevent them from doing so. Finally, some intermediary and server implementations may restrict the size of the request message; they should signal their unwillingness to handle a larger request entity through the 413 status code; see RFC2616 section 10.4.14.