I agree the spec is not perfect. One reason it has so many rough edges is
that it was submitted to W3C, but never taken through the full spec process.
The XML Protocol group will presumably produce a spec with fewer holes
and/or ambiguities.
Scott
----- Original Message -----
From: "Dirk-Willem van Gulik" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 00:06
Subject: Re: Faults and HTTP
>
> On Sun, 22 Jul 2001, Scott Nichol wrote:
>
> > Section 6.2 of SOAP 1.1 states
> >
> > >>>>
> > SOAP HTTP follows the semantics of the HTTP Status codes for
communicating
> > status information in HTTP. For example, a 2xx status code indicates
that
> > the client's request including the SOAP component was successfully
received,
> > understood, and accepted etc.
> >
> > In case of a SOAP error while processing the request, the SOAP HTTP
server
> > MUST issue an HTTP 500 "Internal Server Error" response and include a
SOAP
> > message in the response containing a SOAP Fault element (see section
4.4)
> > indicating the SOAP processing error.
> > <<<<
> >
> > I read the MUST in the second paragraph as requiring faults to be
returned
> > with a 500 status.
>
> IMHO this is a badly written spec. Does that mean that if the backend is
> down, or the HTTP server half died that then the HTTP server needs to be
> able to generate a SOAP message ? The HTTP protocol requires less.
>
> It is one thing to defer to a transport protocol (and all it's semantics)
> but it is quite another thing to defer to it; but then criple it by trying
> to impose your SOAP layer semantics on top of it.
>
> Dw
>
>
>
