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

On Wed, Jul 18, 2001 at 04:04:32PM -0400, Mark Baker wrote:
> >Agree - 500 is a hint that HTTP implementations will believe they can
> >act authoritatively upon. It's misleading; an HTTP server error is
> >not the same as a SOAP server error.
> 
> A SOAP server error *may* be different than an HTTP server error
> (I'll refrain from giving my opinion here), but the issue is how
> that error should be communicated.  

Agreed.


> As SOAP/HTTP reuses HTTP's application semantics (see the charter
> 8-)

reference?


> and HTTP has semantics for communicating errors of this type (5xx).
                                                  ^^^^^^^^^^^^
I think that's making an assumption that it's valid to propogate SOAP
errors into HTTP. When you make a Web stock trade and it fails
because there's not enough money in your account, do you get a 500
response back? Should you? 


> Now, if we decide that a SOAP error is different than an HTTP
> error, I think the question should be *not* about 200 versus 500,
> but about 500 versus a new 5xx error code, e.g. 506 (SOAP Fault).

Jeff Mogul has identified an issue in the HTTP whereby new status
codes don't have any assumed semantics about cacheability, etc., and
thereby may be handled in an unpredictable manner. Additionally, some
intermediaries will barf on an unrecognized status code. This isn't
specified behaviour, but it does happen.

The extension of HTTP by WebDAV, and it's use of new status codes,
etc. has been used to justify the use of SOAP-specific status codes,
etc.; I think this is a false comparison. WebDAV can ONLY be used
over HTTP; it is interwoven with it. 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.


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

Received on Wednesday, 18 July 2001 16:26:48 UTC