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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC