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

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.

Received on Wednesday, 18 July 2001 15:27:45 UTC