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.

This binding can be identified by the following URI:

http:// ...

This binding is the default HTTP binding; that is, implementations SHOULD consider it to be in effect when transporting SOAP messages with HTTP UNLESS some other arrangement is made (e.g., through WSDL).

Encapsulating SOAP Envelopes in HTTP Request Messages

If a SOAP envelope is to be conveyed in an HTTP request, it MUST be the complete content of the message-body, as defined by RFC2616, sections 4.1 and 5.

Implementations receiving SOAP envelopes encapsulated in HTTP request messages MUST handle them irregardless of the request method, UNLESS another arrangment is in effect (e.g., through WSDL, or another formal or informal agreement mechanism). It is RECOMMENDED that implementations use the 'POST' method (RFC 2616, section 9.5) when generating HTTP request messages which encapsulate SOAP envelopes, UNLESS some other arrangement is in effect, as above.

Encapsulating SOAP Envelopes in HTTP Response Messages

If a SOAP envelope is to be conveyed in an HTTP response, it MUST be the complete content of the message-body, as defined by RFC2616, sections 4.1 and 6.

Implementations receiving SOAP envelopes encapsulated in HTTP response messages MUST handle them irregardless of the status code, UNLESS another arrangment is in effect (e.g., through WSDL, or another formal or informal agreement mechanism). It is RECOMMENDED that implementations use the 200 status code (RFC 2616, section 10.2.1) when generating HTTP response messages which encapsulate SOAP envelopes, UNLESS some other arrangement is in effect, as above.

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, UNLESS some other arrangement is in effect (e.g., WSDL, etc.).

Implementation Notes

HTTP is a MIME-like transport, and therefore uses the Content-Type header in both requests and responses to identify their contents, and to enable message dispatch. As a result, the Content-Type HTTP header should reflect the type of the most immediately encapsulated format; if a SOAP message is directly encapsulated, it would be "application/soap+xml".

Implementors should note that some HTTP request methods preclude the presence of a body, or define a syntax for it, and therefore must not encapsulate a SOAP envelope. Likewise, some response status codes preclude the presence of a body or define a syntax, and similarly must not encapsulate a SOAP envelope.

HTTP implementations will typically 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 might signal their unwillingness to handle a larger request entity through the 413 status code; see RFC2616 section 10.4.14.