- From: David Crowley <dcrowley@scitegic.com>
- Date: Wed, 18 Jul 2001 13:29:07 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: Mark Nottingham <mnot@akamai.com>, Doug Davis <dug@us.ibm.com>, xml-dist-app@w3.org
At 01:04 PM 7/18/2001, Mark Baker wrote: >Mark, > >7/18/2001 3:36:24 PM, Mark Nottingham <mnot@akamai.com> 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. As SOAP/HTTP reuses HTTP's >application semantics (see the charter 8-), >and HTTP has semantics for communicating errors of this type (5xx). SOAP errors are communicated with SOAP Fault. HTTP errors are communicated with HTTP status codes. >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). > >My opinion; 500 is good enough, but 506 is probably cleaner. I can live >with either. > >Note that I haven't checked to see if 506 is already taken. > >MB I'm struggling to see why a new code or an existing error code should be setn by HTTP because of a SOAP error. HTTP shouldn't know about SOAP. SOAP shouldn't know about HTTP. HTTP should not have to be extended to handle SOAP. I liken this to adding a new send() or recv() error code because of an application error error. Doug had the right analogy with the Yahoo example. Could you imagine if Yahoo (and MS, CNN, CNET, Excite, etc.) added HTTP status codes for every application or user error?
Received on Wednesday, 18 July 2001 16:31:20 UTC