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

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