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

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

From: David Crowley <dcrowley@scitegic.com>
Date: Wed, 18 Jul 2001 10:51:55 -0700
Message-Id: <5.1.0.14.0.20010718103915.028f2940@pop.business.earthlink.net>
To: Mark Nottingham <mnot@akamai.com>
Cc: xml-dist-app@w3.org
At 10:12 AM 7/18/2001, you wrote:

> > In other words, I think we should allow SOAP applications to use HTTP
> > with all the bells and whistles that HTTP provides including using all
> > status codes and header fields. In other words, let HTTP be HTTP :)
>
>What I'm hearing, then, is that the HTTP binding (and bindings in
>general) should be expansive; e.g.,
>
>* SOAP envelopes can be encapsulated in request messages which have a
>   method which permits an entity body (i.e., POST, PUT)
>
>* SOAP envelopes can be encapsulated in response messsages which have
>   a status code which permits an entity body (i.e., 200, 400, 500,
>   etc.)


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.
Received on Wednesday, 18 July 2001 13:52:02 GMT

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