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

7/18/2001 4:26:47 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> As SOAP/HTTP reuses HTTP's application semantics (see the charter
>> 8-)
>
>reference?

2.4, "Out of Scope; Application Semantics"

>> 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? 

No, that's not a fault.  Why do you ask?

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).

>> 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.

Thanks, I wasn't aware of that.  500 it is. 8-)

>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. 

For the record, it's not the reason why I suggested 506.  I can live with 500.

>WebDAV can ONLY be used
>over HTTP; it is interwoven with it.

Right, because that's what it was required to do; extend HTTP to support locking, etc.

> 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.

MB

Received on Wednesday, 18 July 2001 16:51:10 UTC