- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 26 Jul 2001 09:15:40 -0700
- To: mark.baker@sympatico.ca
- Cc: Rich Salz <rsalz@zolera.com>, xml-dist-app@w3.org
On Wed, Jul 25, 2001 at 09:53:58PM -0400, Mark Baker wrote: > > > But you always get a 200 in the binding that I believe you're > > > promoting. Isn't that a bit inefficient? > > > > Perhaps, trivially so. But it's a worthwhile tradeoff in terms > > of code complexity, etc. > > I would suggest that using a 200 results in more complex code, as > you need to open up the body to find out first, if there's a > problem, and second, what the problem is. How so? If we use 400/500 to signal a Fault, processors (both SOAP and non-SOAP) still need to open up the body to a) assure that it indeed is a SOAP fault b) ascertain the nature of the Fault. More to the point, I still haven't seen any concrete use cases for a device that needs to know the presence of a SOAP fault without cracking open the XML. Meanwhile, there have been several illustrations of devices that will misuse this information in the mistaken belief that it is a hint as to the nature of the HTTP message in a Web browsing context. > > > How else would you suggest we allow firewall administrators to > > > disallow SOAP invocations over their firewalls? > > > > We should tell them: that's not the way to make things secure. > > How so? HTTP invocations are secure by virtue of their meanings > being publicly specified, and examined by security conscious folks. > If the XMLP WG cannot guarantee that the only SOAP based protocols > being tunneled over HTTP have been through this same process, then > you need a way to turn SOAP tunneling off. I'm not exactly sure what you mean here - could you expand on this? Thanks, -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 26 July 2001 12:15:44 UTC