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

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 18:03:22 UTC