- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Tue, 16 Aug 2005 23:00:42 -0700
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- CC: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Marc, Looks good to me. One issue that needs to be addressed from an interop perspective is: What do we say about the entity body on the 202 response? Is it required to be empty? If not, are there any restriction wrt its content? Basic Profile does not allow an entity body for the 202 response. It makes sense to me to keep things consistent with the Basic Profile, but there may be good reasons (that I don't know of) for allowing non-empty entity body on a 202 response. Regardless, it would be really strange and confusing, if there was a SOAP env returned with the 202 response, followed by another SOAP env sent to the wsa:ReplyTo endpoint. -Anish -- Marc Hadley wrote: > Here's an excerpt from a proposal[6] I sent to the async TF that > describes the changes I think are necessary to the existing HTTP > binding to make it useable with non-anonymous WS-Addr ReplyTo and FaultTo. > >> 1. SOAP 1.2 HTTP Binding >> >> Tweak the existing SOAP 1.2 binding[1] as follows. >> >> 1.1 New Features >> >> Say that it supports the SOAP 1.2 Addressing 1.0 feature[2] using the >> SOAP 1.2 Addressing 1.0 Module[3]. >> >> 1.2 Update table 17[4] >> >> Add a new row for HTTP response code 202 >> >> Status Code: 202 >> reason phrase: Accepted >> Significance/Action: The response message (if any) will be sent to >> the node identified by the http://www.w3.org/@@@@/@@/addressing/ >> feature/ReplyEndpoint property of the SOAP 1.2 Addressing 1.0 >> feature[2]. >> NextState: Success >> >> 1.3 Update table 19[5] >> >> Update row describing status line to support HTTP response code 202: >> >> Change: "200, or set according to Table 20 if a SOAP fault was >> generated." >> To: "200, 202 or set according to Table 20 if a SOAP fault was >> generated. 202 is used when the http://www.w3.org/@@@@/@@/ >> addressing/feature/ReplyEndpoint property of the SOAP 1.2 Addressing >> 1.0 feature requires a response to be sent to an alternate >> destination. In this case the responding node follows the behaviour >> described in 7.5.1 Behavior of Requesting SOAP Node to send the >> response message to the specified destination." >> >> Update row describing HTTP entity body: >> >> Change: "SOAP message serialized according to the rules for carrying >> SOAP messages in the media type given by the Content-Type header field." >> To: "Empty or SOAP message serialized according to the rules for >> carrying SOAP messages in the media type given by the Content-Type >> header field." > > > Marc. > > [1] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp > [2] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- > soap.html?content-type=text/html;%20charset=utf-8#s12feature > [3] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- > soap.html?content-type=text/html;%20charset=utf-8#s12module > [4] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/ > #tabreqstatereqtrans > [5] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/ > #tabresstaterecheads > [6] http://www.w3.org/mid/F37A5A89-14D6-4A46-96EC-E2581E7D43F6@Sun.COM > > On Aug 10, 2005, at 1:03 PM, Anish Karmarkar wrote: > >> Forwarding it to dist-app for discussion. >> >> -Anish >> -- >> >> From: Anish Karmarkar <Anish.Karmarkar@oracle.com> >> Date: August 10, 2005 2:05:29 AM EDT >> To: "'w3c-xml-protocol-wg@w3.org' " <w3c-xml-protocol-wg@w3.org> >> Subject: Does the SOAP/HTTP binding require a SOAP env in the response >> >> >> I took an action to send a proposal to the WG to answer the question >> that has been raised in the WS-Addressing [1], WSD [2][3], (as well >> as in the async TF). >> >> The question: >> When using the SOAP HTTP binding [4], and the request-response MEP >> [5], is it required that the SOAP response be sent over the HTTP >> response for the success case? >> >> Suggested answer: >> >> Per the SOAP HTTP binding for the request-response MEP, the SOAP >> response has to be sent as the entity-body of the HTTP response, in >> the success case. >> >> Section 7.5.2.2 of SOAP 1.2 part 2. Table 19 makes it clear that the >> HTTP entity body of the HTTP Response must contain the SOAP message >> and the status line is either 200 or as described by table 20. >> >> Sections 7.5.1.2, 7.5.1.3 and 7.5.1.4 also support this. From section >> 7.5.1.2: >> 'In cases where "Fail" is one of the choices, the transition is >> dependent on whether a SOAP message is present in the HTTP response. >> If a SOAP message is present, the next state is "Sending +Receiving" >> or Receiving", otherwise the next state is "Fail".' >> >> From section 7.5.1.3: >> 'The response message is assumed to contain a SOAP envelope serialized >> according to the rules for carrying SOAP messages in the media type >> given in the Content-Type header field.' >> >> From section 7.5.1.4: >> 'The response message is assumed to contain a SOAP envelope serialized >> according to the rules for carrying SOAP messages in the media type >> given in the Content-Type header field.' >> >> Although the SOAP HTTP binding does not allow an empty entity-body in >> the HTTP response for the success case, SOAP does allow one to: >> 1) write a new binding to transport SOAP over HTTP that supports the >> request-response MEP and does allow such a behavior >> 2) write a SOAP header specification that changes how the SOAP HTTP >> binding works. >> >> >> Comments? >> >> -Anish >> -- >> >> [1] http://lists.w3.org/Archives/Public/public-ws-addressing/ >> 2005Jun/0107.html >> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2004Nov/0003.html >> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2004Jul/0012.html >> [4] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp >> [5] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/ >> #singlereqrespmep >> >> >> >> > > --- > Marc Hadley <marc.hadley at sun.com> > Business Alliances, CTO Office, Sun Microsystems. > >
Received on Wednesday, 17 August 2005 06:02:15 UTC