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 12:36:24 -0700
To: Doug Davis <dug@us.ibm.com>
Cc: David Crowley <dcrowley@scitegic.com>, xml-dist-app@w3.org
Message-ID: <20010718123613.B24690@akamai.com>


Agree - 500 is a hint that HTTP implementations will believe they can
act authoritatively upon. It's misleading; an HTTP server error is
not the same as a SOAP server error.



On Wed, Jul 18, 2001 at 03:27:42PM -0400, Doug Davis wrote:
> Isn't this a lot like what happens when you fail to log into something like
> yahoo?
> >From HTTP's point of view it was a successful request (200 status code)
> but the body of the messages says "login failed".
> -Dug
> 
> 
> David Crowley <dcrowley@scitegic.com>@w3.org on 07/18/2001 01:51:55 PM
> 
> Sent by:  xml-dist-app-request@w3.org
> 
> 
> To:   Mark Nottingham <mnot@akamai.com>
> cc:   xml-dist-app@w3.org
> Subject:  Re: another approach to status codes, etc. in HTTP binding
> 
> 
> 
> 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.
> 
> 
> 

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

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