- From: Mark Baker <mbaker@markbaker.ca>
- Date: Wed, 25 Jul 2001 21:53:58 -0400 (EDT)
- To: rsalz@zolera.com (Rich Salz)
- Cc: xml-dist-app@w3.org
> > I answered this one already. HTTP response code 401 is very > > specific to HTTP authentication and does not include SOAP > > signatures. > > okay, then 403. :) But my binding suggests using 400. Asking what I'd do with a 403 is a red herring. (sorry, should have answered that for your 401 question) > > 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 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. FWIW, this is another advantage of my proposed use of SOAP. By adopting the semantics of the underlying application protocol, SOAP also adopts the security model of that protocol (for the most part - still need to consider security when designing the binding). MB
Received on Thursday, 26 July 2001 02:05:10 UTC