> If we try to make the SOAP fault (or lack of) mirror (or respect) the HTTP > status codes, then we are making SOAP tied into HTTP, and *not* protocol > independent. > </Pete wrote> > > +1 Well, to respond to Pete, I'm not trying to tie SOAP faults to HTTP status codes, I'm just tying it to HTTP in the HTTP binding. > Mark, > > The SOAP application layer is interested in the SOAP fault. Ultimately, it > is the sender of the SOAP request/msg that needs to be notified of the SOAP > fault. Pardon my ignorance of Transport Intermediary processing, but please > describe a scenario where a SOAP processing fault, wrapped in a 200 HTTP > message, would hinder a transport intermediary from assuming such roles as > proxy, gateway or store and forward node. Let's say I had a HTTP proxy that tracked my purchasing habits for me. If a SOAP fault came back on a 200 when I submitted a purchase order, my proxy would assume that the purchase was successful when it was not. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.comReceived on Thursday, 28 March 2002 10:11:50 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT