Re: Issue #12: HTTP Status Codes 500 v 200

(( I promise to make this brief, then return to lurking.. ))

 From what I understand, SOAP is _not_ an extension of HTTP, instead 
it is a protocol with an HTTP binding. I really hope that other 
bindings remain possible.

Pushing SOAP status information up into HTTP seems to me like a hack 
that's going to cause no end of headaches for other bindings (what 
happens when an intermediary needs to translate from HTTP<->UDP? does 
it have to parse all the messages going back HTTP-side so it can stick 
in the right error code? ugh..). Also, it complicates the spec.

I like the XML-RPC take on the issue: "Unless there's a lower-level 
error, always return 200 OK.".

Thanks for listening,

- Dan Gunter

Philip Eskelin wrote:

> Section 5.3 of RFC 2616 says that the request header fields of a request
> sent between a Web client and server allow the client to express additional
> information about the request and about the client itself to the server that
> will be serving the request. These fields are request modifiers, with
> semantics equivalent to the parameters on a programming language method
> invocation. So it turns out that HTTP is a very adequate protocol from which
> distributed apps can be built upon.
> 
> If only the SOAP guys had the outlook of extending HTTP, usings request
> modifiers to express its extra semantics above and beyond HTTP.  You don't
> force SOAP faults to translate into existing HTTP status codes, you extend
> the protocol with modifiers that deal with the faults in a semantically
> clear manner.
> 
> ----- Original Message -----
> From: "Mark Baker" <distobj@acm.org>
> To: <xml-dist-app@w3.org>
> Sent: Sunday, June 03, 2001 2:44 AM
> Subject: Re: Issue #12: HTTP Status Codes 500 v 200
> 
> 
> 
>>My 2c on this issue (I like tackling the tough ones 8-)
>>
>>SOAP is one way of extending HTTP's (or many other application
>>protocol's) semantics.  It is *not* a layer above HTTP in the same way
>>that WebDAV isn't a layer on top of HTTP.  SOAP and WebDAV are both
>>extensions of HTTP.  SOAP just happens to extend HTTP in a way that HTTP
>>wasn't expecting (to say the least - and FWIW, this isn't a good thing).
>>
>>A SOAP fault carried on an HTTP response must therefore use HTTP
>>semantics as best it can.  There are four types of SOAP fault;
>>
>>- version mismatch
>>- must understand
>>- client
>>- server
>>
>>The last one clearly maps quite cleanly to a 500.  The third one maps
>>cleanly to 400. (*)  The other two aren't as straightforward.
>>
>>The "Version Mismatch" fault looks a bit like a 505 ("HTTP Version Not
>>Supported"), but not exactly, since 505 is specific to HTTP versioning,
>>not SOAP versioning.  But I certainly believe that either 500, or a new
>>5xx code should communicate the intent.
>>
>>The "Must Understand" fault is quite close to a 417 ("Expectation
>>Failed" - part of the HTTP 1.1 Expect feature).  It's a 4xx ("Client
>>Error") presumably because if the request hadn't been sent with that
>>Expect header, you'd be fine.  I suggest that either 400 or a new 4xx
>>status code (not 417, as that's specific to Expect) be used for must
>>understand as well.
>>
>>(*) I would normally suggest that using the specific 5xx or 4xx status
>>codes (rather than 400 and 500) should be used, but as SOAP is trying to
>>be application-protocol neutral, I can understand its desire not to.
>>
>>I hope that was helpful.
>>
>>MB
>>
>

Received on Thursday, 7 June 2001 20:39:55 UTC