- From: David Crowley <dcrowley@scitegic.com>
- Date: Wed, 18 Jul 2001 10:51:55 -0700
- 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 UTC