- From: Appleton, Pete M <PMAppleton@bemis.com>
- Date: Thu, 28 Mar 2002 09:21:12 -0600
- To: "'Mark Baker'" <distobj@acm.org>, highland.m.mountain@intel.com
- cc: "Appleton, Pete M" <PMAppleton@bemis.com>, xml-dist-app@w3.org
> > 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. HTTP is transport - the HTTP codes should have semantic meaning only to the transport layer. > > > 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. How can an HTTP proxy track your purchasing habits? Shouldn't this be a SOAP intermediary? If an HTTP proxy is tracking, this implies that the message contents have semantic meaning to it (the HTTP proxy), which implies that it is more than just an HTTP proxy. Pete Appleton Information Systems Controller, Bemis Packaging Limited pmappleton@bemis.com
Received on Thursday, 28 March 2002 10:21:55 UTC