- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 27 Mar 2002 19:18:59 +0100 (MET)
- To: noah_mendelsohn@us.ibm.com
- cc: Mark Baker <distobj@acm.org>, "Mountain, Highland M" <highland.m.mountain@intel.com>, <xml-dist-app@w3.org>
On Tue, 26 Mar 2002 noah_mendelsohn@us.ibm.com wrote: > * If the application protocol (e.g. HTTP) has a standard means of > signaling that the message being transmitted represents failure at the > application level, a binding to that protocol MAY (and in many cases > SHOULD) adopt such signal when transmitting a SOAP fault message. That's > why we use HTTP 4XX and 5XX for SOAP faults. The strange thing here is that we use the HTTP semantic for signaling errors and we are not using it for the method used. This leads to the confusion between a) and c) (* see [3]) Currently, I see our use of HTTP error codes as being an optimization for the upper layer. > In short, I disagree strongly with the suggestion that any binding would > be the principal determinant of whether a message carried a SOAP fault. I > do think that a well constructed binding can ensure that there is never > disagreement between what's in the envelope and signals encoded in the > underlying protocol. In such cases, the binding-specific signal may be > taken as a highly reliable hint. that any binding yes, but the current HTTP binding preclude sending a fault with a 200 return code, as Henrik stated in [4]. If a fault is sent using the wrong return code, it is then because 1/ we are not using the same binding (so we don't know if the features are well supported) 2/ because the implementation is broken, and we can't assume the message will be processed the right way. [3] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0267.html [4] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0242.html -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Wednesday, 27 March 2002 13:19:08 UTC