8.4 SOAP Transport Binding and HTTP

To actually get SOAP messages from one node to another, you must use some underlying transport protocol, such as HTTP [RFC 2616] or SMTP [RFC 2821, 2822]. The extent to which you must augment or restrict the transport protocol varies depending on how closely the native mechanism of the protocol matches the needs of SOAP.

By convention, most TCP/IP-based protocols have a default "port" number for example, port 80 for HTTP and port 25 for SMTP. Servers that support a protocol normally have, listening on the default port, a process that handles incoming service requests. The SOAP specification recommends the use of a different port number when you use an existing transport protocol with SOAP. This recommendation reflects the fact that the service being requested is SOAP service, rather than the service for which the transport protocol was originally intended. For example, HTTP was originally developed to support Web browsing. Although you can accommodate both that use and SOAP on the default HTTP port 80, it is simpler and more efficient to have separate processes servicing and optimized for these different kinds of requests on different ports.

8.4.1 Transport Message Exchange Patterns

The XML Protocol Working Group is developing a general model for transport mechanism patterns and their binding to SOAP. Such patterns describe the following aspects of transport:

• The life cycle of transport exchange messages

• The temporal order and causal relationships of multiple messages being exchanged

• Normal and abnormal termination of message exchange

The Transport Message Exchange Pattern (TMEP) model is complex; readers are referred to [SOAP] for its detail. The only TMEP specified thus far is the Single-Request-Response TMEP, named in the current draft by the URI "http://www.example.org/2001/12/soap/transport-mep-single-request-response."

8.4.2 The SOAP HTTP Binding

The Hypertext Transfer Protocol [RFC 2616] is a convenient protocol to use for SOAP. HTTP is based on a request response model that works well when the single request response TMEP is being used in SOAP. However, the semantic match is not complete, so some interpretation is required [SOAP]. For example, HTTP intermediaries (such as proxies) are not necessarily SOAP intermediaries.

Although it is not mentioned in the SOAP specification, one reason SOAP uses HTTP is that firewalls are ubiquitously configured to let HTTP pass through. This approach is very convenient when you are trying to get from a client or peer inside one firewall out through the general Internet to a server or peer inside another firewall. It is much less desirable from a security point of view, however. SOAP can access very general interfaces, including remote procedure calls to system facilities, for example.

The increasing tendency to layer protocols on top of HTTP makes firewall filtering at the protocol level useless because it requires that you choose one of three options:

1. Having the firewall block a fundamental protocol such as HTTP or SMTP

2. Letting the protocol through and then worrying about securing all machines inside the firewall

3. Making the firewall more complex and knowledgeable by having it look inside the protocol and try to figure out if the contained message, perhaps SOAP, is safe

In general, option 1 is too painful and option 2 is probably the appropriate choice, as the "hard exterior shield and soft, insecure inside" security model is a proven loser. Of course, this brings up an obvious question: Why are you paying for a fancy firewall? People therefore tend to choose option 3, which leads to a spiral of evasion measures and countermeasures and decreased firewall reliability resulting from the increased complexity.

When carrying SOAP in HTTP, you must take three considerations into account:

• You can use only the HTTP "POST" method.

• You must label the body (i.e., the SOAP message) with the "application/soap" MIME type.

• You may include a "SOAPAction:" HTTP Header in requests and "required-SOAPAction:" in responses, for optimization purposes.

You use the SOAPAction Header as a optional hint to optimize processing. It takes a URI, which can be relative or absolute. If the URI is relative, interpret it using the HTTP Request-URI as a base. If a SOAP receiver does not require it, it must ignore the absence of this Header or the presence of an incorrect SOAPAction Header. Conversely, if a SOAP receiver requires this Header, and none is present or the receiver does not recognize the one provided, it must respond with the following HTTP error status code:

 427 "SOAPAction Required" 

An HTTP response with this 427 status code may have a Required-SOAPAction Header that gives a URI that a SOAPAction Header can use in a resubmission of the HTTP request. The following example shows a SOAPAction request Header:

 SOAPAction: "http://www.foo.example/path#fragment" 

The following example shows a Required-SOAPAction response Header:

 Required-SOAPAction: "example://www.bar.example?query" 

[SOAP] contains detailed tables describing how to create and respond to other HTTP error codes. These responses generally preserve the existing HTTP semantics of the codes.