Copyright © W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
SOAP Version 1.2 provides a request-response MEP and 2 request-response bindings. This provides a 1 way MEP with an optional binding defined response, and a 1 way binding to HTTP request/response that supports SOAP request-response and the 1 way MEP. This specification depends on SOAP Version 1.2 Part 2: Adjuntcts [SOAP-PART2].
This document is an editors' copy that has no official standing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
1 Introduction
1.1 Notational Conventions
2 Request Response Message Exchange Pattern
2.1 SOAP Feature Name
2.2 Description
2.3 Property Description
3 WS-Addressing HTTP binding
3.1 Introduction
3.1.1 Optionality
3.1.2 Use of HTTP
3.1.3 HTTP Media-Type
3.2 Binding Name
3.3 Supported Message Exchange Patterns
3.4 Supported Features
3.5 Message Exchange Pattern Operation
3.5.1 Behavior of Requesting Node
3.5.1.1 Init
3.5.1.2 Requesting
3.5.1.3 Sending+Receiving
3.5.1.4 Success and Fail
3.5.2 Behavior of Responding Node
3.5.2.1 Init
3.5.2.2 Receiving
3.5.2.3 Receiving+Sending
3.5.2.4 Success and Fail
3.6 Security Considerations
4 References
4.1 Normative References
4.2 Informative References
A Change Log (Non-Normative)
SOAP Version 1.2 (SOAP) provides 2 SOAP MEPs and 1 HTTP Binding. This specification provides a request-response MEP and an HTTP binding. The primary difference is that this specification's MEPs and Bindings do not follow the SOAP Binding framework..
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119].
This specification uses a number of namespace prefixes throughout; they are listed in ???. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see XML Infoset [XML InfoSet]).
| Prefix | Namespace | Notes |
|---|---|---|
| env | "http://www.w3.org/2003/05/soap-envelope" | Defined by SOAP 1.2 Part 1 [SOAP Part 1]. |
| xs | "http://www.w3.org/2001/XMLSchema" | Defined in the W3C XML Schema specification [XML Schema Part 1], [XML Schema Part 2]. |
Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent application or context-dependent URIs (see RFC 2396 [RFC 2396]).
This specification uses the Extended Backus-Naur Form (EBNF) as described in XML 1.0 [XML 1.0].
With the exception of examples and sections explicitly marked as "Non-Normative", all parts of this specification are normative.
This section defines the message exchange pattern (MEP) called "Request Response". The description is an abstract presentation of the operation of this MEP. It is not intended to describe a real implementation or to suggest how a real implementation should be structured.
This message exchange pattern is identified by the URI (see SOAP 1.2 Part 1 [SOAP Part 1]SOAP Features):
"http://www.w3.org/2004/12/ws-addr/mep/request-response/"
The Request Response MEP defines a pattern for the exchange of a message acting as a request optionally followed by a response. In the absence of failure in the underlying protocol, this MEP consists of one request message and one optional response message:
A request message which may contain a SOAP envelope.
An optional response message which may contain a SOAP Envelope. The MEP is completed by the processing of response message.
Abnormal operation during a Request-Response message exchange might be caused by a failure to transfer the request message, a failure at the responding node to process the request message, or failure to transfer the response message. Such failures might be silent at either or both of the requesting and recieving nodes involved, or might result in the generation of a SOAP or binding-specific fault (see ???). Also, during abnormal operation each node involved in the message exchange might differ in its determination of the successful completion of the message exchange.
The scope of a Request Resposne MEP is limited to the exchange of a request message between one requesting and one responding node and the exchange of an optional response message. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.
The Request Response MEP defines a set of properties described in ???.
| Property Name | Property Description | Property Type |
|---|---|---|
http://www.w3.org/2004/12/ws-addr/mep/RequestMessage | An abstract structure that represents the current request message in the message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope. | Not specified |
http://www.w3.org/2004/12/ws-addr/mep/ImmediateDestination | The identifier of the immediate destination of an request message. | xs:anyURI |
http://www.w3.org/2004/12/ws-addr/mep/ImmediateSender | The identifier of the immediate sender of an inbound message. | xs:anyURI |
http://www.w3.org/2004/12/ws-addr/mep/ResponseMessage | An abstract structure that represents the current response message in the message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope. | Not specified |
http://www.w3.org/2004/12/ws-addr/mep/ResponseStatus | Response status, either Success or Failure | Not specified |
The WS-Addressing HTTP binding provides a binding of messages to HTTP. The binding does NOT conform to the SOAP Protocol Binding Framework (see SOAP 1.2 Part 1 [SOAP Part 1]SOAP Protocol Binding Framework). It supports the message exchange patterns and features described in ???.
The WS-Addressing HTTP Binding is optional and nodes are NOT required to implement it. A node that correctly and completely implements the SOAP HTTP Request Binding may to be said to "conform to the WS-Addressing HTTP Binding."
The WS-Addressing HTTP binding defines a base URI according to the rules in HTTP/1.1 [RFC 2616]. I.e. the base URI is the HTTP Request-URI or the value of the HTTP Content-Location header field.
This binding of request-response to HTTP is intended to make appropriate use of HTTP as an application protocol. For example, successful responses are sent with status code 200, and failures are indicated as 4XX or 5XX. This binding is not intended to fully exploit the features of HTTP, but rather to use HTTP specifically for the purpose of communicating with other nodes implementing the same binding. Therefore, this HTTP binding does not specify the use and/or meaning of all possible HTTP methods, header fields and status responses. It specifies only those which are pertinent to the ??? or which are likely to be introduced by HTTP mechanisms (such as proxies) acting between the nodes.
Certain optional features provided by this binding depend on capabilities provided by HTTP/1.1, for example content negotiation. Implementations SHOULD thus use HTTP/1.1 [RFC 2616] (or later compatible versions that share the same major version number). Implementations MAY also be deployed using HTTP/1.0, although in this case certain optional binding features may not be provided.
Note:
WS-Addressing HTTP Binding implementations need to account for the fact that HTTP/1.0 intermediaries (which may or may not also be SOAP intermediaries) may alter the representation of SOAP messages, even in situations where both the initial SOAP sender and ultimate SOAP receiver use HTTP/1.1.
Conforming implementations of this binding:
MUST be capable of sending and receiving messages serialized using media type "application/soap+xml" whose proper use and parameters are described in ???.
MAY send requests and responses using other media types providing that such media types provide for at least the transfer of SOAP XML Infoset.
MAY, when sending requests, provide an HTTP Accept header field. This header field:
SHOULD indicate an ability to accept at minimum "application/soap+xml".
MAY additionally indicate willingness to accept other media types that satisfy 2 above.
This binding is identified by the URI :
"http://www.w3.org/2004/12/ws-addr/bindings/HTTP/"
An implementation of the WS-Addressing HTTP Binding MUST support at least the following message exchange pattern (MEP):
"http://www.w3.org/2004/12/ws-addr/mep/request-response/" (see ???)
An implementation of the WS-Addressing HTTP Binding MUST support the following features:
"http://www.w3.org/2003/05/soap/features/action/" (see ???)
An HTTP node can be a Requesting or Responding HTTP Node. The remainder of this section describes the WS-Addressing HTTP Binding state machine and its relationship to the HTTP Protocol. In the state tables below, the states are not explicity identified .
The overall flow of the behavior of a requesting node follows a state machine description. This binding supports streaming and, as a result, requesting nodes MUST avoid deadlock by accepting and if necessary processing response information while therequest is being transmitted (see 2.3 Property Description). The following subsections describe each state in detail.
In the "Init" state, a HTTP request is formulated according to ??? and transmission of the request is initiated.
| Field | Value |
|---|---|
| HTTP Method | According to the http://www.w3.org/2003/05/soap/features/web-method/Method property. |
| Request URI | The value of the URI carried in the
http://www.w3.org/2004/12/ws-addr/mep/ImmediateDestination property of the
message exchange context. |
Content-Type header field | The media type of the request entity body (if present) otherwise,
omitted (see 3.1 Introduction for a description of permissible media types).
If the SOAP envelope infoset in the http://www.w3.org/2004/12/ws-addr/mep/OutboundMessage property is null,
then the Content-Type header field MAY be omitted. |
action parameter | According to the value of the |
Accept header field (optional) | List of media types that are acceptable in response to the request message. |
Additional header fields | Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange. For example, a Content-Encoding header field (see HTTP [RFC 2616], section 14.11) may be used to express an optional compression feature. |
| HTTP entity body | A message serialized according to the rules for
carrying messages in the media type given by the
Content-Type header field. Rules for carrying SOAP messages in
media type "application/soap+xml" are given
in ???. If the SOAP envelope infoset in the
|
In the "Requesting" state, sending of the request continues while waiting for the start of the optional response message. ??? details the transitions that take place when a requesting node receives an HTTP status line and response header fields. For some status codes there is a choice of possible next state. In cases where "Fail" is one of the choices, the next state is "Fail".
| Status Code | Reason phrase | Significance/Action | NextState |
|---|---|---|---|
| 2xx | Successful | ||
| 200 | OK | An optional response message follows in the HTTP response entity body. Start making an abstraction of the response message available in http://www.w3.org/2004/12/ws-addr/mep/ResponseMessage . | "Sending+Receiving" or "Success" |
| 202 | OK | The request has completed succesfully. The HTTP response entity body will be empty. | "Success" |
| 3xx | Redirection | The requested resource has
moved and the HTTP request SHOULD be retried using the URI carried in the
associated Location header field as the new value for the
| "Init" |
| 4xx | Client Error | ||
| 400 | Bad Request | Indicates a problem with the received HTTP request message. | "Sending+Receiving" or "Fail" |
| 401 | Unauthorized | Indicates that the HTTP request requires authorization. If the simple authentication feature is unavailable or the operation of simple authentication ultimately fails, then the message exchange is regarded as having completed unsuccessfully. | "Requesting" or "Fail" |
| 405 | Method not allowed | Indicates that the peer HTTP server does not support the requested HTTP method at the given request URI. The message exchange is regarded as having completed unsuccessfully. | "Fail" |
| 415 | Unsupported Media Type | Indicates that the peer HTTP server does not support the Content-type used to encode the request message. The message exchange is regarded as having completed unsuccessfully. | "Fail" |
| 5xx | Server Error | ||
| 500 | Internal Server Error | Indicates a server problem or a problem with the received request | "Sending+Receiving" or "Fail" |
??? refers to some but not all of the existing HTTP/1.1 [RFC 2616] status codes. In addition to these status codes, HTTP provides an open-ended mechanism for supporting status codes defined by HTTP extensions (see RFC 2817 [RFC 2817] for a registration mechanism for new status codes). HTTP status codes are divided into status code classes as described in HTTP [RFC 2616], section 6.1.1. The WS-Addressing HTTP Binding follows the rules of any HTTP application which means that an implementation of the WS-Addressing HTTP Binding must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached.
Note:
There may be elements in the HTTP infrastructure configured to modify HTTP response entity bodies for 4xx and 5xx status code responses. For example, some HTTP origin servers have such a feature as a configuration option. This behavior may interfere with the use of 4xx and 5xx status code responses carrying SOAP fault messages in HTTP and it is recommended that such behavior is disabled for resources accepting SOAP/HTTP requests. If the rewriting behavior cannot be disabled, SOAP/HTTP cannot be used in such configurations.
In the "Sending+Receiving" state (??? only), the transmission of the request message and receiving of the response message is completed. This response message may contain a SOAP envelope serialized according to the rules for carrying SOAP messages in the media type given in the Content-Type header field.
The response MAY be of content type other than "application/soap+xml". Such usage is considered non-normative, and accordingly is not modeled in the state machine. Interpretation of such responses is at the discretion of the receiver.
The overall flow of the behavior of a responding node follows a state machine. The following subsections describe each state in detail.
In the "Init" state, the binding waits for the start of an inbound request message. ??? describes the errors that a responding node might generate while in the "Init" state. In this state no SOAP message has been received, therefore the node cannot generate a SOAP fault.
| Problem with Message | HTTP Status Code | HTTP Reason Phrase (informative) |
|---|---|---|
| Malformed Request Message | 400 | Bad request |
| HTTP Method not supported | 405 | Method Not Allowed |
| Unsupported message encapsulation method | 415 | Unsupported Media |
In the "Receiving" state, the binding receives the request and any associated message and waits for the start of a response message to be available. ??? describes the HTTP response header fields generated by the responding node. ??? describes the HTTP status codes that can be generated by the responding node.
| Field | Value |
|---|---|
| Status line | 200, 202, or set according to ??? if a SOAP fault was generated. |
Content-Type header field | The media type of the response body, see 3.1 Introduction for a description of permissible media types. |
Additional header fields | Generated in accordance with the rules for the binding specific expression of any optional features in use for this message exchange. For example, a Content-Encoding header field (see HTTP [RFC 2616], section 14.11) may be used to express an optional compression feature. |
| HTTP Entity Body | Optional body. It MUST be empty for HTTP Status code 202. It MAY contain a SOAP message serialized according to the rules for carrying SOAP messages in the media type given by the Content-Type header field. Rules for carrying SOAP messages in "application/soap+xml" are given in ???. |
| SOAP Fault | HTTP Status Code | HTTP Reason Phrase (informative) |
|---|---|---|
| env:VersionMismatch | 500 | Internal server error |
| env:MustUnderstand | 500 | Internal server error |
| env:Sender | 400 | Bad request |
| env:Receiver | 500 | Internal server error |
| env:DataEncodingUnknown | 500 | Internal server error |
The WS-Addressing HTTP Binding can be considered as an extension of the HTTP application protocol. As such, all of the security considerations identified and described in section 15 of the HTTP specification [RFC 2616] apply to the WS-Addressing HTTP Binding in addition to those described in SOAP 1.2 Part 1 [SOAP Part 1]Security Considerations. Implementors of the WS-Addressing HTTP Binding should carefully review this material.