Re: Fault HTTP status 500

I understand what you mean and, after following the links on a previous post about the previous threads on this subject,
I'm afraid I fall into the 200 camp. I don't think HTTP should be an integral part of SOAP. If I choose another
transport other than HTTP then, to be consistent I should use that other transport's error mechanism in a similar way.
So, if I do SOAP over JMS, SMTP, etc. then error reporting should also be done outside of SOAP as well as passing a SOAP
fault. This means that for each transport over which SOAP will be sent we need a specification of how errors should be
reported.

If we simply use Faults and don't tell the transport that there was an error then there is no need for a specification
of how to report errors on each transport. It is already intrinsically a part of SOAP.

I think the previous thread said it all, there are 2 distinct camps in this argument and there's not much point in
rehashing it.

Thanks for the response.

Pete

Mark Nottingham wrote:
> 
> 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:57:38 UTC