6. 在HTTP中使用SOAP
本节描述了如何在使用或不使用HTTP Extension Framework的前提下将SOAP与HTTP的协同工作机制。将SOAP绑定在HTTP上可以利用HTTP丰富的特性集，提供使用SOAP形式方法和分布适应性的优点。将SOAP在HTTP上传输并不以为着SOAP可以完全超越HTTP的语义，更恰当的描述应当是SOAP的语义通过HTTP的映射而很自然地成为HTTP的语义。
SOAP很自然地利用HTTP的请求/响应消息模型，将SOAP请求的参数放在HTTP请求里，而将SOAP响应的参数放在HTTP响应里面。注意，无论如何，SOAP的中间介与HTTP中间介是不同的。也就是说，根据HTTP Connection头字段来寻址的HTTP中间介一般并不能来处理HTTP请求中的SOAP实体体。
当需要将SOAP消息体包含在HTTP消息中时，HTTP应用程序必须依照RFC2376 [3] 使用媒体类型“text/xml”。
6.1 SOAP HTTP请求
虽然SOAP可以和多种HTTP请求方法联合使用，但这里的绑定只定义了SOAP是如何在HTTP Post请求中传输的。(可参阅 section 7 了解如何在RPC中使用SOAP，以及 section 6.3 如何使用HTTP Extension Framework)
6.1.1 HTTP Header中的SOAPAction字段
SOAPAction HTTP请求头字段(header field)可以用于指示SOAP HTTP请求的目的。它的值是一个标识该目的的URI。SOAP对于格式上并没有严格的限制，同时对URI的描述以及是否要是可解析的都没有严格的限制。当发出SOAP HTTP请求时，HTTP客户必须使用该头字段。
| soapaction | = | "SOAPAction" ":" [ <"> URI-reference <"> ] |
|---|---|---|
| URI-reference | = |
1<as 2396="" [4]="" defined="" in="" rfc="">
2
3SOAPAction头字段的存在及其内容可以被服务器例如防火墙用于在HTTP中过滤SOAP请求消息。当该字段的值为空字符串( “”)时，则意味着SOAP消息的目的由HTTP Request-URI来提供。而如果没有值则表示对消息的目的没有指示。
4
5例如:
6
7Example 42
8
9
10 SOAPAction: "http://electrocommerce.org/abc#MyMessage"
11 SOAPAction: "myapp.sdl"
12 SOAPAction: ""
13 SOAPAction:
14
15Examples of values for SOAPAction
16
17### 6.2 **SOAP HTTP响应**
18
19在HTTP之上的SOAP遵从用于在HTTP中表示通讯状态的HTTP状态代码的语义。例如，2xx状态代码表明这是客户端包含SOAP构件的请求被成功的接收、理解和接受等等。
20
21当处理请求的时候发生SOAP错误的时候，SOAP HTTP服务器必须发出一个HTTP 500 “Internal Server Error”响应同时在包含于该响应的SOAP消息中应包含一个SOAP Fault元素(参阅 section 4.4 )来指明SOAP处理的错误。
22
23### 6.3 **HTTP扩展框架**
24
25SOAP消息可以与HTTP Extension Framework [6] 一起使用来标识SOAP HTTP请求的出现和意图。
26
27是使用Extension Framework还是使用简单HTTP对于通讯各方而言是一个策略及能力的问题。客户端可以通过一个强制扩展声明以及一个“M-”HTTP方法名前缀来强制使用HTTP Extension Framwork。服务器端可以通过使用 510 “Not Extended” HTTP状态代码来强制使用HTTP Extension Framework。也就是说，通过一次额外的环游，每个通讯方都可以检测到其他通讯方和因此的动作。
28
29用于使用Extension Framework标识SOAP的扩展标识是:
30
31
32 http://www.w3.org/2001/06/soap-envelope
33
34### 6.4 **SOAP HTTP示例**
35
36Example 43
37
38
39 POST /StockQuote HTTP/1.1
40 Content-Type: text/xml; charset="utf-8"
41 Content-Length: nnnn
42 SOAPAction: "http://electrocommerce.org/abc#MyMessage"
43
44 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
45 . . .
46 </env:envelope>
47
48SOAP HTTP Request Using POST
49
50Example 44
51
52
53 HTTP/1.1 200 OK
54 Content-Type: text/xml; charset="utf-8"
55 Content-Length: nnnn
56
57 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
58 . . .
59 </env:envelope>
60
61SOAP HTTP Response to Example 43
62
63Example 45
64
65
66 M-POST /StockQuote HTTP/1.1
67 Man: "http://www.w3.org/2001/06/soap-envelope"; ns=NNNN
68 Content-Type: text/xml; charset="utf-8"
69 Content-Length: nnnn
70 NNNN-SOAPAction: "http://electrocommerce.org/abc#MyMessage"
71
72 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
73 . . .
74 </env:envelope>
75
76SOAP HTTP Request using the experimental HTTP Extension Framework
77
78Example 46
79
80
81 HTTP/1.1 200 OK
82 Ext:
83 Content-Type: text/xml; charset="utf-8"
84 Content-Length: nnnn
85
86 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
87 . . .
88 </env:envelope>
89
90SOAP HTTP Response to Example 45
91
92## 7\. **在RPC中使用SOAP**
93
94SOAP的一个设计目标就是要利用XML的可扩展性和可伸缩性来包装和交换RPC调用。本节定义了一个统一的远程过程调用和响应的表示。
95
96其实我们也可以预想到在RPC环境下的表示很可能是与在其他表示中定义的编码风格结合。SOAP encodingStyle属性(参阅 section 4.3.2 )可以被用于指明在本节表示中使用的方法调用/响应的编码风格。
97
98在RPC中使用SOAP与SOAP协议绑定(参阅 section 6 )基本是正交的。在使用HTTP作为SOAP协议绑定媒介的情况下，一个RPC调用可以很自然地映射到一个HTTP请求，而RPC响应则可以映射到HTTP响应。无论如何，使用SOAP方式的RPC并不限于HTTP协议绑定。
99
100为实施一个方法调用，需要以下信息:
101
102 * 目标SOAP结点的URI
103
104 * 方法名
105
106 * 可选的方法或过程的特征
107
108 * 方法或过程的参数
109
110 * 可选的头数据
111
112
113
114
115SOAP依赖协议绑定来提供传送URI的机制。例如，对HTTP而言，请求URI指明了与该调用相对应的资源。除要求该URI是合法的以外，SOAP对于该地址没有任何限制(参阅 [4] 以获得URI的更多信息)。
116
117### 7.1 **RPC和SOAP Body**
118
119RPC调用和响应都是在SOAP Body元素(参阅 section 4.3 )中传送，使用如下表示方式:
120
121 * 一个方法调用被建模成一个结构struct。
122
123 * 该方法调用显示为一个简单结构struct，包含每个[in]或[in/out]参数的存取标识。该结构的名和类型可使用过程或方法的名来标识。
124
125 * 每个[in]或[in/out]参数都被表示为一个存取标识，该存取标识的名和类型都对应于相应参数的名和类型。他们的次序也是按照原来RPC中的次序。
126
127 * 一个方法响应被建模成一个结构struct。
128
129 * 该方法响应显示为一个简单结构struct，包含每个[out]或[in/out]参数的存取标识。而第一个存取标识是返回值，而随后则是按照原来次序的返回参数。
130
131 * 每个[out]或[in/out]参数都被表示为一个存取标识，该存取标识的名和类型都对应于相应参数的名和类型。返回值的存取标识名并没有多少语义。同样的，结构的名也并没有多少语义。当然，无论如何，在添加了“Response”字串的方法名后，要有一个约定来命名它。
132
133 * 方法调用出错应使用SOAP Fault元素来编码(餐饮 section 4.4 )。如果一个绑定协议对于错误表达还有额外规则，那么这些规则都应当被遵守。
134
135
136
137
138就象先前表述的那样，方法和响应的结构可以使用在 section 5 中定义的规则来编码，也可以使用在encodingStyle属性中描述的其他编码(参阅 section 4.1.1 )。
139
140应用程序可以处理漏写参数的请求不过也可以返回一个错误。
141
142因为在响应中若包含“result”则表明成功，若包含“fault”则表明失败，所以如果方法响应中同时包含了“result”和“fault”则是错误的。
143
144### 7.2 **RPC和SOAP Header**
145
146对于那些并非是方法的正式调用数据部分，而是方法请求编码相关的一些额外信息，也可以在RPC编码中表示。如果这样，它必须作为SOAP Header元素的一个子元素来描述。
147
148对于使用header元素的一个例子是在消息中传送一个事务ID。事务ID并不是调用参数表中的一员，它一般是要被下层构件所处理而不仅仅是一个应用程序ID，而这里并没有一个直接的方法在调用中传送这一需要的信息。通过在头上加一个条目并赋予它一个固定的名字，接收方的事务管理器就可以将该事务ID抽取出来，同时就可以在不影响远程过程调用的代码的前提下使用它。
149
150## 8\. **安全机制的考虑**
151
152在本文档中并不包含完整性和私密性保护的方法的描述。这些问题将在本文档的以后版本中详细说明。
153
154## 9\. **参考文献**
155
156### 9.1. Normative references
157
158**[2]** IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" , S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt
159
160**[3]** IETF "RFC 2376: XML Media Types" , E. Whitehead, M. Murata, July 1998. Available at http://www.ietf.org/rfc/rfc2376.txt
161
162**[4]** IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax" , T. Berners-Lee, R. Fielding, L. Masinter, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt
163
164**[5]** IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1" , R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. Available at http://www.ietf.org/rfc/rfc2616.txt
165
166**[6]** IETF "RFC 2774: An HTTP Extension Framework" , H. Nielsen, P. Leach, S. Lawrence, February 2000. Available at http://www.ietf.org/rfc/rfc2774.txt
167
168**[7]** W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)" , Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. Available at http://www.w3.org/TR/2000/REC-xml-20001006
169
170**[8]** W3C Recommendation "Namespaces in XML" , Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. Available at http://www.w3.org/TR/1999/REC-xml-names-19990114/
171
172**[9]** W3C Proposed Recommendation "XML Linking Language (XLink) Version 1.0" , Steve DeRose, Eve Maler, David Orchard, 20 December 2000. Available at http://www.w3.org/TR/2000/PR-xlink-20001220/
173
174**[10]** W3C Recommendation "XML Schema Part 1: Structures" , Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
175
176**[11]** W3C Recommendation "XML Schema Part 2: Datatypes" , Paul V. Biron, Ashok Malhotra, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
177
178### 9.2. Informative references
179
180**[12]** Transfer Syntax NDR, in Open Group Technical Standard "DCE 1.1: Remote Procedure Call" , August 1997. Available at http://www.opengroup.org/public/pubs/catalog/c706.htm
181
182**[13]** IETF "RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" , N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt
183
184## A. SOAP Envelope Examples
185
186### A.1 Sample Encoding of Call Requests
187
188Example 47
189
190
191 POST /StockQuote HTTP/1.1
192 Host: www.stockquoteserver.com
193 Content-Type: text/xml; charset="utf-8"
194 Content-Length: nnnn
195 SOAPAction: "http://example.org/2001/06/quotes"
196
197 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
198<env:header>
199<t:transaction env:encodingstyle="http://www.w3.org/2001/06/soap-encoding" env:mustunderstand="1" xmlns:t="http://example.org/2001/06/tx">
200 5
201 </t:transaction>
202</env:header>
203<env:body>
204<m:getlasttradeprice env:encodingstyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes">
205<m:symbol>DEF</m:symbol>
206</m:getlasttradeprice>
207</env:body>
208</env:envelope>
209
210Similar to Example 1 but with a Mandatory Header
211
212Example 48
213
214
215 POST /StockQuote HTTP/1.1
216 Host: www.stockquoteserver.com
217 Content-Type: text/xml; charset="utf-8"
218 Content-Length: nnnn
219 SOAPAction: "http://example.org/2001/06/quotes"
220
221 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
222<env:body>
223<m:getlasttradepricedetailed env:encodingstyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes">
224<symbol>DEF</symbol>
225<company>DEF Corp</company>
226<price>34.1</price>
227</m:getlasttradepricedetailed>
228</env:body>
229</env:envelope>
230
231Similar to Example 1 but with multiple request parameters
232
233### A.2 Sample Encoding of Response
234
235Example 49
236
237
238 HTTP/1.1 200 OK
239 Content-Type: text/xml; charset="utf-8"
240 Content-Length: nnnn
241
242 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
243<env:header>
244<t:transaction env:encodingstyle="http://www.w3.org/2001/06/soap-encoding" env:mustunderstand="1" xmlns:t="http://example.org/2001/06/tx" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:int">
245 5
246 </t:transaction>
247</env:header>
248<env:body>
249<m:getlasttradepriceresponse env:encodingstyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes">
250<price>34.5</price>
251</m:getlasttradepriceresponse>
252</env:body>
253</env:envelope>
254
255Similar to Example 2 but with a Mandatory Header
256
257Example 50
258
259
260 HTTP/1.1 200 OK
261 Content-Type: text/xml; charset="utf-8"
262 Content-Length: nnnn
263
264 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
265<env:body>
266<m:getlasttradepriceresponse env:encodingstyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes">
267<priceandvolume>
268<lasttradeprice>34.5</lasttradeprice>
269<dayvolume>10000</dayvolume>
270</priceandvolume>
271</m:getlasttradepriceresponse>
272</env:body>
273</env:envelope>
274
275Similar to Example 2 but with a Struct
276
277Example 51
278
279
280 HTTP/1.1 500 Internal Server Error
281 Content-Type: text/xml; charset="utf-8"
282 Content-Length: nnnn
283
284 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
285<env:body>
286<env:fault>
287<faultcode>env:MustUnderstand</faultcode>
288<faultstring>SOAP Must Understand Error</faultstring>
289</env:fault>
290</env:body>
291</env:envelope>
292
293Similar to Example 2 but Failing to honor Mandatory Header
294
295Example 52
296
297
298 HTTP/1.1 500 Internal Server Error
299 Content-Type: text/xml; charset="utf-8"
300 Content-Length: nnnn
301
302 <env:envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
303<env:body>
304<env:fault>
305<faultcode>env:Server</faultcode>
306<faultstring>Server Error</faultstring>
307<detail>
308<e:myfaultdetails xmlns:e="http://example.org/2001/06/faults">
309<message>My application didn't work</message>
310<errorcode>1001</errorcode>
311</e:myfaultdetails>
312</detail>
313</env:fault>
314</env:body>
315</env:envelope>
316
317Similar to Example 2 but Failing to handle Body
318
319## B. Acknowledgements
320
321This document is the work of the W3C XML Protocol Working Group.
322
323Members of the Working Group are (at the time of writing, and by alphabetical order): Yasser al Safadi (Philips Research), Vidur Apparao (Netscape), Don Box (DevelopMentor), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion (Software AG), David Clay (Oracle), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Ron Daniel (Interwoven), Glen Daniels (Allaire), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Brian Eisenberg (Data Channel), David Ezell (Hewlett-Packard), James Falek (TIBCO Software, Inc.), David Fallside (IBM), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Martin Gudgin (Develop Mentor), Hugo Haas (W3C), Marc Hadley (Sun Microsystems), Mark Hale (Interwoven), Randy Hall (Intel), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Compaq), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Software Corporation), Murali Janakiraman (Rogue Wave), Mario Jeckle (Daimler-Chrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (IDOOX s.r.o.), Alan Kropp (Epicentric), Yves Lafon (W3C), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Richard Martin (Active Data Exchange), Noah Mendelsohn (Lotus Development), Nilo Mitra (Ericsson Research Canada), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Software Corporation), Mark Needleman (Data Research Associates), Eric Newcomer (IONA Technologies), Henrik Frystyk Nielsen (Microsoft Corporation), Mark Nottingham (Akamai Technologies), David Orchard (JamCracker), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (Daimler-Chrysler Research and Technology), Hervé Ruellan (Canon), Marwan Sabbouh (MITRE Corporation), Shane Sesta (Active Data Exchange), Miroslav Simek (IDOOX s.r.o.), Simeon Simeonov (Allaire), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Randy Waldrop (WebMethods), Ray Whitmer (Netscape), Volker Wiechers (SAP AG), Stuart Williams (Hewlett-Packard), Amr Yassin (Philips Research) and Dick Brooks (Group 8760). _ Previous members were _ : Eric Fedok (Active Data Exchange) Susan Yee (Active Data Exchange) Alex Milowski (Lexica), Bill Anderson (Xerox), Ed Mooney (Sun Microsystems), Mary Holstege (Calico Commerce), Rekha Nagarajan (Calico Commerce), John Evdemon (XML Solutions), Kevin Mitchell (XML Solutions), Yan Xu (DataChannel) Mike Dierken (DataChannel) Julian Kumar (Epicentric) Miles Chaston (Epicentric) Bjoern Heckel (Epicentric) Dean Moses (Epicentric) Michael Freeman (Engenia Software) Jim Hughes (Fujitsu Software Corporation) Francisco Cubera (IBM), Murray Maloney (Commerce One), Krishna Sankar (Cisco), Steve Hole (MessagingDirect Ltd.) John-Paul Sicotte (MessagingDirect Ltd.) Vilhelm Rosenqvist (NCR) Lew Shannon (NCR) Henry Lowe (OMG) Jim Trezzo (Oracle) Peter Lecuyer (Progress Software) Andrew Eisenberg (Progress Software) David Cleary (Progress Software) George Scott (Tradia Inc.) Erin Hoffman (Tradia Inc.) Conleth O'Connell (Vignette) Waqar Sadiq (Vitria Technology Inc.) Tom Breuel (Xerox) David Webber (XMLGlobal Technologies) Matthew MacKenzie (XMLGlobal Technologies) and Mark Baker (Sun Microsystems).
324
325This document is based on the SOAP/1.1 specification whose authors were: Don Box (Develop Mentor), David Ehnebuske (IBM), Gopal Kakivaya (Microsoft Corp.), Andrew Layman (Microsoft Corp.) Noah Mendelsohn (Lotus Development Corp.), Henrik Frystyk Nielsen (Microsoft Corp.), Satish Thatte (Microsoft Corp.) and Dave Winer (UserLand Software, Inc.).
326
327We also wish to thank all the people who have contributed to discussions on xml-dist-app@w3.org .
328
329## C. Version Transition From SOAP/1.1 to SOAP Version 1.2
330
331EdNote: The scope of the mechanism provided in this section is for transition between SOAP/1.1 and SOAP version 1.2. The Working Group is considering providing a more general transition mechanism that can apply to any version. Such a general mechanism may or may not be the mechanism provided here depending on whether it is deemed applicable.
332
333The SOAP/1.1 specification says the following on versioning in section 4.1.2 :
334
335> "SOAP does not define a traditional versioning model based on major and minor version numbers. A SOAP message MUST have an Envelope element associated with the "http://schemas.xmlsoap.org/soap/envelope/" namespace. If a message is received by a SOAP application in which the SOAP Envelope element is associated with a different namespace, the application MUST treat this as a version error and discard the message. If the message is received through a request/response protocol such as HTTP, the application MUST respond with a SOAP VersionMismatch faultcode message (see section 4.4) using the SOAP "http://schemas.xmlsoap.org/soap/envelope/" namespace."
336
337That is, rather than a versioning model based on shortnames (typically version numbers), SOAP uses a declarative extension model which allows a sender to include the desired features within the SOAP envelope construct. SOAP says nothing about the granularity of extensions nor how extensions may or may not affect the basic SOAP processing model. It is entirely up to extension designers be it either in a central or a decentralized manner to determine which features become SOAP extensions.
338
339The SOAP extensibility model is based on the following four basic assumptions:
340
341 1. SOAP versioning is directed only at the SOAP envelope. It explicitly does not address versioning of blocks, encodings, protocol bindings, or otherwise.
342 2. A SOAP node must determine whether it supports the version of a SOAP message on a per message basis. In the following, "support" means understanding the semantics of the envelope version identified by the QName of the Envelope element:
343 * A SOAP node receiving an envelope that it doesn't support must not attempt to process the message according to any other processing rules regardless of other up- or downstream SOAP nodes.
344 * A SOAP node may provide support for multiple envelope versions. However, when processing a message a SOAP node must use the semantics defined by the version of that message.
345 3. It is essential that the envelope remains stable over time and that new features are added using the SOAP extensibility mechanism. Changing the envelope inherently affects interoperability, adds complexity, and requires central control of extensions -- all of which directly conflicts with the SOAP requirements.
346 4. No versioning model or extensibility model can prevent buggy implementations. Even though significant work has been going into clarifying the SOAP processing model, there is no guarantee that a SOAP 1.2 implementation will behave correctly. Only extensive testing within the SOAP community and design simplicity at the core can help prevent/catch bugs.
347
348
349
350The rules for dealing with the possible SOAP/1.1 and SOAP Version 1.2 interactions are as follows:
351
352 1. Because of the SOAP/1.1 rules, a compliant SOAP/1.1 node receiving a SOAP Version 1.2 message will generate a VersionMismatch SOAP fault using an envelope qualified by the "http://schemas.xmlsoap.org/soap/envelope/" namespace identifier.
353 2. A SOAP Version 1.2 node receiving a SOAP/1.1 message may either process the message as SOAP/1.1 or generate a SOAP VersionMismatch fault using the "http://schemas.xmlsoap.org/soap/envelope/" namespace identifier. As part of the SOAP VersionMismatch fault, a SOAP Version 1.2 node should include the list of envelope versions that it supports using the SOAP upgrade extension identified by the "http://www.w3.org/2001/06/soap-upgrade" identifier.
354
355
356
357The upgrade extension contains an ordered list of namespace identifiers of SOAP envelopes that the SOAP node supports in the order most to least preferred. Following is an example of a VersionMismatch fault generated by a SOAP Version 1.2 node including the SOAP upgrade extension:
358
359Example 53
360
361
362 <env:envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
363<env:header>
364<v:upgrade xmlns:v="http://www.w3.org/2001/06/soap-upgrade">
365<envelope qname="ns1:Envelope" xmlns:ns1="http://www.w3.org/2001/06/soap-envelope"></envelope>
366</v:upgrade>
367</env:header>
368<env:body>
369<env:fault>
370<faultcode>env:VersionMismatch</faultcode>
371<faultstring>Version Mismatch</faultstring>
372</env:fault>
373</env:body>
374</env:envelope>
375
376VersionMismatch fault generated by a SOAP Version 1.2 node, and including a SOAP upgrade extension
377
378Note that existing SOAP/1.1 nodes are not likely to indicate which envelope versions they support. If nothing is indicated then this means that SOAP/1.1 is the only supported envelope.
379
380## D. Change Log
381
382### D.1 SOAP Specification Changes
383
384Date | Author | Description
385---|---|---
38620010629 | MJG | Amended description of routing and intermediaries in Section 2.1
38720010629 | JJM | Changed "latest version" URI to end with soap12
38820010629 | JJM | Remove "previous version" URI
38920010629 | JJM | Removed "Editor copy" in <title>
39020010629 | JJM | Removed "Editor copy" in the title.
39120010629 | JJM | Added "Previous version" to either point to SOAP/1.1, or explicitly mention there was no prior draft.
39220010629 | JJM | Pre-filed publication URIs.
39320010629 | JJM | Incorporated David's suggested changes for the examples in section 4.1.1 to 4.4.2
39420010629 | JJM | Fixed some remaining typos.
39520010629 | MJH | Fixed a couple of typos.
39620010628 | MJG | Made various formatting, spelling and grammatical fixes.
39720010628 | MJG | Moved soap:encodingStyle from soap:Envelope to children of soap:Header/soap:Body in examples 1, 2, 47, 48, 49 and 50
39820010628 | MJG | Changed text in Section 2.1 from 'it is both a SOAP sender or a SOAP receiver' to 'it is both a SOAP sender and a SOAP receiver'
39920010628 | MJG | Fixed caption on Example 24
40020010628 | MJH | Fixed a couple of capitalisation errors where the letter A appeared as a capital in the middle of a sentence.
40120010628 | MJH | Updated figure 1, removed ednote to do so.
40220010622 | HFN | Removed the introductory text in terminology section 1.4.3 as it talks about model stuff that is covered in section 2. It was left over from original glossary which also explained the SOAP model.
40320010622 | HFN | Moved the definition of block to encapsulation section in terminology
40420010622 | HFN | Removed introductory section in 1.4.1 as this overlaps with the model description in section 2 and doesn't belong in a terminology section
40520010622 | HFN | Removed reference to " Web Characterization Terminology & Definitions Sheet " in terminology section as this is not an active WD
40620010622 | HFN | Added revised glossary
40720010622 | HFN | Added example 0 to section 1.3 and slightly modified text for example 1 and 2 to make it clear that HTTP is used as a protocol binding
40820010622 | MJG | Added http://andsky.com/... to list of application/context specific URIs in section 1.2
40920010622 | MJG | Updated examples in section 4.1.1 to be encodingStyle attributes rather than just the values of attributes
41020010622 | MJG | Added table.norm, td.normitem and td.normtext styles to stylesheet. Used said styles for table of fault code values in section 4.4.1
41120010622 | MJG | In Appendix C, changed upgrade element to Upgrade and env to envelope. Made envelope unqualified. Updated schema document to match.
41220010622 | MJG | Moved MisunderstoodHeader from envelope schema into seperate faults schema. Removed entry in envelope schema change table in Appendix D.2 that refered to additon of said element. Modified example in section 4.4.2 to match. Added reference to schema document to section 4.4.2
41320010622 | MJH | Added binding as a component of SOAP in introduction. Fixed a couple of typos and updated a couple of example captions.
41420010622 | MJG | Made BNF in section 6.1.1 into a table.
41520010622 | MJG | Made BNFs in section 5.1 clause 8 into tables. Added associated 'bnf' style for table and td elements to stylesheet
41620010622 | MJG | Amended text regarding namespace prefix mappings in section 1.2
41720010622 | MJG | Added link to schema for the http://www.w3.org/2001/06/soap-upgrade namespace to Appendix C. Updated associated ednote.
41820010622 | MJG | Added reference numbers for XML Schema Recommendation to text prior to schema change tables in Appendix D.2 and linked said numbers to local references in this document
41920010622 | MJG | Reordered entries in schema change classification table in Appendix D.2
42020010622 | MJG | Changed type of mustUnderstand and root attributes to standard boolean and updated schema change tables in Appendix D.2 accordingly
42120010622 | JJM | Manually numbered all the examples (53 in total!)
42220010622 | JJM | Added caption text to all the examples
42320010622 | JJM | Replaced remaining occurrences of SOAP/1.2 with SOAP Version 1.2 (including <title>)
42420010621 | HFN | Added ednote to section 4.2.2 and 4.2.3 that we know they have to be incorporated with section 2
42520010621 | HFN | Added version transition appendix C
42620010621 | HFN | Applied new styles to examples
42720010621 | HFN | Changed term "transport" to "underlying protocol
42820010621 | HFN | Changed example URNs to URLs of the style http://example.org/...
42920010621 | MJH | Updated the Acknowledgements section.
43020010621 | JJM | Added new style sheet definitions (from XML Schema) for examples, and used them for example 1 and 2.
43120010621 | JJM | Incorporated David Fallside's comments on section Status and Intro sections.
43220010620 | HFN | Changed the status section
43320010620 | HFN | Changed title to SOAP Version 1.2 and used that first time in abstract and in body
43420010620 | HFN | Removed question from section 2.4 as this is an issue and is to be listed in the issues list
43520010620 | HFN | Moved change log to appendix
43620010615 | JJM | Renamed default actor to anonymous actor for now (to be consistent)
43720010615 | JJM | Fixed typos in section 2
43820010614 | JJM | Updated section 2 to adopt the terminology used elsewhere in the spec.
43920010613 | MJH | Updated mustUnderstand fault text with additions from Martin Gudgin.
44020010613 | MJH | Added schema changes appendix from Martin Gudgin.
44120010613 | MJH | Added mustUnderstand fault text from Glen Daniels.
44220010612 | MJH | Fixed document <title>.
44320010612 | MJH | Moved terminology subsection from message exchange model section to introduction section.
44420010612 | MJH | Fixed capitalisation errors by replacing "... A SOAP ..." with "... a SOAP ..." where appropriate.
44520010612 | MJH | Removed trailing "/" from encoding namespace URI.
44620010612 | MJH | Fixed links under namespace URIs to point to W3C space instead of schemas.xmlsoap.org.
44720010612 | MJH | Removed some odd additional links with text of "/" pointing to the encoding schema following the text of the encoding namespace URI in several places.
44820010611 | MJH | Incorporated new text for section 2.
44920010611 | JJM | Changed remaining namespaces, in particular next.
45020010609 | JJM | Changed the spec name from XMLP/SOAP to SOAP.
45120010609 | JJM | Changed the version number from 1.1 to 1.2.
45220010609 | JJM | Changed the namespaces from http://schemas.xmlsoap.org/soap/ to http://www.w3.org/2001/06/soap-.
45320010609 | JJM | Replaced the remaining XS and XE prefixes to env and enc, respectively.
45420010601 | MJH | Updated the examples in section 1, 6 and appendix A with text suggested by Martin Gudgin to comply with XML Schema Recommendation.
45520010601 | JJM | Updated the examples in section 4 and 5 with text suggested by Martin Gudgin, to comply with XML Schema Recommendation.
45620010531 | HFN | Removed appendices C and D and added links to live issues list and separate schema files.
45720010531 | MJH | Added this change log and updated schemas in appendix C to comply with XML Schema Recommendation.
458
459### D.2 XML Schema Changes
460
461The envelope and encoding schemas have been updated to be compliant with the XML Schema Recomendation[ 10 , 11 ]. The table below shows the categories of change.
462
463Class | Meaning
464---|---
465Addition | New constructs have been added to the schema
466Clarification | The meaning of the schema has been changed to more accurately match the specification
467Deletion | Constructs have been removed from the schema
468Name | The schema has been changed due to a datatype name change in the XML Schema specification
469Namespace | A namespace name has been changed
470Semantic | The meaning of the schema has been changed
471Style | Style changes have been made to the schema
472Syntax | The syntax of the schema has been updated due to changes in the XML Schema specification
473
474The table below lists the changes to the envelope schema.
475
476Class | Description
477---|---
478Namespace | Updated to use the http://www.w3.org/2001/XMLSchema namespace
479Namespace | Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-envelope
480Clarification | Changed element and attribute wildcards in Envelope complex type to namespace="##other"
481Clarification | Changed element and attribute wildcards in Header complex type to namespace="##other"
482Clarification | Added explicit namespace="##any" to element and attribute wildcards in Body complex type
483Clarification | Added explicit namespace="##any" to element and attribute wildcards in detail complex type
484Clarification | Added an element wildcard with namespace="##other" to the Fault complex type
485Name | Changed item type of encodingStyle from uri-reference to anyURI
486Name | Changed type of actor attribute from uri-reference to anyURI
487Name | Changed type of faultactor attribute from uri-reference to anyURI
488Semantic | Added processContents="lax" to all element and attribute wildcards
489Semantic | Changed type of the mustUnderstand attribute from restriction of boolean that only allowed 0 or 1 as lexical values to the standard boolean in the http://www.w3.org/2001/XMLSchema namespace. The lexical forms 0, 1, false, true are now allowed.
490Style | Where possible comments have been changed into annotations
491Syntax | Changed all occurences of maxOccurs="*" to maxOccurs="unbounded"
492Syntax | Added <xs:sequence> to all complex type definitions derived implicitly from the ur-type
493Syntax | Added <xs:sequence> to all named model group definitions
494
495The table below lists the changes to the encoding schema.
496
497Class | Description
498---|---
499Namespace | Updated to use the http://www.w3.org/2001/XMLSchema namespace
500Namespace | Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-encoding
501Semantic | Changed type of the root attribute from restriction of boolean that only allowed 0 or 1 as lexical values to the standard boolean in the http://www.w3.org/2001/XMLSchema namespace. The lexical forms 0, 1, false, true are now allowed.
502Addition | Added processContents="lax" to all element and attribute wildcards
503Syntax | Changed base64 simple type to be a vacuous restriction of the base64Binary type in the http://www.w3.org/2001/XMLSchema namespace
504Syntax | Updated all complex type definitions with simple base types to new syntax
505Syntax | Added <xs:sequence> to all complex type definitions derived implicitly from the ur-type
506Syntax | Added <xs:sequence> to all named model group definitions
507Deletion | Removed the timeDuration datatype
508Addition | Added duration datatype derived by extension from the duration datatype in the http://www.w3.org/2001/XMLSchema namespace.
509Deletion | Removed the timeInstant datatype
510Addition | Added dateTime datatype derived by extension from the dateTime datatype in the http://www.w3.org/2001/XMLSchema namespace.
511Addition | Added gYearMonth datatype derived by extension from the gYearMonth datatype in the http://www.w3.org/2001/XMLSchema namespace.
512Addition | Added gYear datatype derived by extension from the gYear datatype in the http://www.w3.org/2001/XMLSchema namespace.
513Addition | Added gMonthDay datatype derived by extension from the gMonthDay datatype in the http://www.w3.org/2001/XMLSchema namespace.
514Addition | Added gDay datatype derived by extension from the gDay datatype in the http://www.w3.org/2001/XMLSchema namespace.
515Addition | Added gDay datatype derived by extension from the gDay datatype in the http://www.w3.org/2001/XMLSchema namespace.
516Deletion | Removed the binary datatype
517Addition | Added hexBinary datatype derived by extension from the hexBinary datatype in the http://www.w3.org/2001/XMLSchema namespace.
518Addition | Added base64Binary datatype derived by extension from the base64Binary datatype in the http://www.w3.org/2001/XMLSchema namespace.
519Deletion | Removed the uriReference datatype
520Addition | Added anyURI datatype derived by extension from the anyURI datatype in the http://www.w3.org/2001/XMLSchema namespace.
521Addition | Added normalizedString datatype derived by extension from the normalizedString datatype in the http://www.w3.org/2001/XMLSchema namespace.
522Addition | Added token datatype derived by extension from the token datatype in the http://www.w3.org/2001/XMLSchema namespace.
523Clarification | Added explicit namespace="##any" to all element and attribute wildcards which did not previously have an explicit namespace attribute
524Style | Where possible comments have been changed into annotations
525
526In addition several changes occured in the names of datatypes in the XML Schema specification and some datatypes were removed. The following table lists those changes.
527
528Datatype | Class | Description
529---|---|---
530timeDuration | Renamed | New name is duration
531timeInstant | Renamed | New name is dateTime
532recurringDuration | Removed | The recurringDuration datatype no longer exists.
533recurringInstant | Removed | The recurringInstant datatype no longer exists.
534binary | Removed | The binary datatype has been replaced by the hexBinary and base64Binary datatypes.
535month | Renamed | New name is gYearMonth
536timePeriod | Removed | The timePeriod datatype no longer exists
537year | Renamed | New name is gYear
538century | Removed | The century datatype no longer exists
539recurringDate | Renamed | New name is gMonthDay
540recurringDay | Renamed | New name is gDay
541
542* * *
543
544Last Modified: $Date: 2001/07/09 13:39:15 $ UTC</xs:sequence></xs:sequence></xs:sequence></xs:sequence></title></title></title></as>