Re: another approach to status codes, etc. in HTTP binding

On Wed, Jul 18, 2001 at 04:50:42PM -0400, Mark Baker wrote:
> >> As SOAP/HTTP reuses HTTP's application semantics (see the charter
> >> 8-)
> >
> > reference?
> 
> 2.4, "Out of Scope; Application Semantics"

That's taking it completely out of context. Section 2.4 is a call to
avoid the specification of *SOAP* application semantics. How does
that translate to a requirement to reuse HTTP's application
semantics?


> SOAP defines a server fault as;
> 
> "The Server class of errors indicate that the message could not be
> processed for reasons not directly attributable to the contents of
> the message itself but rather to the processing of the message. For
> example, processing could include communicating with an upstream
> processor, which didn't respond. The message may succeed at a later
> point in time."
> 
> HTTP defines the 5xx class of response codes as;
> 
> "... indicate cases in which the server is aware that it has erred
> or is incapable of performing the request."
> 
> and 500 specifically as;
> 
> "The server encountered an unexpected condition which prevented it
> from fulfilling the request."
> 
> I believe the meaning of a SOAP server fault fits within the
> definition of 500 (and implicitly, the definition of 5xx).

"Server" is being used in two different contexts (their respective
documents). An HTTP server is very different from a SOAP server, and
may be implemented by a completely different process.



> > SOAP is designed to be portable across different bindings, and is
> >this aspect more of a content format than an HTTP extension. I
> >don't see any concrete benefits to conflating the semantics of
> >SOAP and HTTP, and several possible dangers.
> 
> I don't see how what I suggest conflates anything.

See above.

-- 
Mark Nottingham
http://www.mnot.net/

Received on Wednesday, 18 July 2001 17:53:40 UTC