Default SOAP HTTP Binding

This document describes a binding for SOAP to HTTP/1.1, as described by RFC2616. It 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., as described through WSDL).

Encapsulating SOAP Envelopes in HTTP Messages

HTTP defines two types of messages capable of carrying SOAP envelopes; request and response.

HTTP is capable of encapsulating formats such as SOAP by conveying them as the complete content of the message-body, defined in RFC2616 section 4.1. SOAP envelopes may be encapsulated in HTTP messages directly, in which case the Content-Type HTTP header MUST be "application/soap+xml", or they may be wrapped by one or more encapsulation bindings, in which case the Content-Type HTTP header MUST reflect the appropriate MIME type.

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 description or negotiation 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.

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.

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 description or negotiation 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.

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

HTTP Protocol Characteristics (non-normative)

SOAP applications which use the HTTP binding MUST be compliant with the requirements stated in RFC2616; the following sections only highlight the nature and capabilities of HTTP in the context of SOAP.

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. Therefore, a SOAP application can potentially build one of three different message exchange patterns out of a single HTTP transaction;

1. client -> server one-way message
2. server -> client one-way message
3. client -> server -> client request/response message pattern

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.

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

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.

HTTP Protocol Services (non-normative)

The following services may be provided by or through HTTP; SOAP applications may use them when the HTTP binding is in use.

• 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.
• format negotiation - clients can advertise the Content-Types, including encapsulation formats, which they are willing to receive with the "Accept" HTTP request header.
• compression - HTTP message compression can be negotiated through either the Accept-Encoding/Content-Encoding mechanism, or the TE/Transfer-Encoding mechanism.
• 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).

This is not a complete feature list for HTTP/1.1; please refer to RFC2616 for more information.

Implementation Notes (non-normative)

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 and/or cache messages as they pass through; use of the Cache-Control mechanisms (RFC2616, section 14.9) may or may not prevent them from doing so.

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.