- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 9 Oct 2001 09:27:06 -0700
- To: Pete Hendry <peter.hendry@capeclear.com>
- Cc: xml-dist-app@w3.org
Hi Pete, I don't think that HTTP status codes are used to *indicate* a SOAP Fault; only the Fault-like XML elements in the SOAP message can do that. HTTP status codes are used to align the semantics of the SOAP messages (success, failure) with the HTTP message semantics (success, failure), so that the HTTP semantics are preserved/respected. This is because there is not as clean a separation between SOAP and HTTP as one would think from looking at the layering diagrams; HTTP is an application protocol, and has application semantics. Does that help? Cheers, On Mon, Oct 08, 2001 at 07:15:49PM +0100, Pete Hendry wrote: > > I'd like clarification on the reason for using an HTTP error status > to indicate a soap fault. I'd also like the reason behind using 500 > which is the 'Internal Server Error' code. > > In my opinion, if the message reached the SOAP processor, then HTTP > has done its job and then it is on to the application to generate > errors in its own way. SOAP has its own error mechanism (fault) > which is separate from HTTP. HTTP is simply the SOAP carrier. Why > do we therefore have to use an HTTP error code to indicate a fault > within the SOAP application? > > I would prefer that HTTP error codes be used by the web server and > the SOAP processor return a fault with HTTP status 200 (i.e. not an > HTTP error). I see no reason that the code handing off to the SOAP > processor should be concerned with the fact that the returned > message contains a Fault. That is beyond its responsibility. > > Thanks for any clarification on this. > > Pete > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 9 October 2001 12:27:10 UTC