W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

Re: Fault HTTP status 500

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
Message-ID: <20011009092700.A10195@mnot.net>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT