W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

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

From: Mark Nottingham <mnot@akamai.com>
Date: Wed, 18 Jul 2001 11:13:35 -0700
To: David Crowley <dcrowley@scitegic.com>
Cc: xml-dist-app@w3.org
Message-ID: <20010718111324.B23653@akamai.com>

On Wed, Jul 18, 2001 at 10:51:55AM -0700, David Crowley wrote:
> 
> While I _absolutely_ agree with "let HTTP be HTTP," I am concerned
> about SOAP responses being in any response message other than 2xx. 
> We should not mix _protocol_ errors with SOAP errors.  SOAP has a
> way of dealing with errors through the SOAP Fault.  Just because
> SOAP returns a fault, doesn't mean that HTTP (or any other
> underlying protocol) should signal an error.  It's not an error
> with the underlying protocol.
> 
> Specifically, requiring an error code 500 for a SOAP Fault, IMHO,
> is just plain wrong. Internal Error 500 - "The server encountered
> an unexpected condition which prevented it from fulfilling the
> request." If the server returns a valid SOAP Fault message, then
> the server absolutely fulfilled the request.

In practical terms, I agree with this view; it's a mistake to
conflate the semantics of an *HTTP* server error and a *SOAP* server
error. HTTP implementations (clients, servers and intermediaries) may
perform operations based on the HTTP semantics (Larry Masinter's
favourite example is Apache; it has a module that automagically
'prettifies' 500 errors).

Two possible approaches, then, are:

* Specify a few messages (POST and 200) that can carry SOAP
  envelopes. (i.e., SOAP implementations should always use these
  semantics when generating SOAP messages; they must be able to
  handle a wider range when they're receiving)

* Don't specify any specific status codes, methods, etc., and leave
  HTTP to HTTP, but warn people of the possible implications of
  conflating semantics.


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
Received on Wednesday, 18 July 2001 14:13:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:02 GMT