Re: A tale of two bindings

> > 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.

I'm not sure why a) would be necessary.  It's part of what's
required to do b), but I don't see it as useful by itself.
Also, the HTTP response status code gives you some information
about the nature of the fault, just not as much as the body
would.  But it would be enough information to take action in
many cases.

Looking into a SOAP Fault would be analogous to knowing the
exact HTTP response status code, whereas knowing what type of
fault was returned would be analogous to knowing the first
digit of the response code.

> 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 can anybody misuse a *subset* of the information that would be
available to you if you cracked open the body?  It's not like you're
going to find anything in there that would tell you that the HTTP
response code you saw was the wrong one.

> > 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? 

HTTP's application semantics are secure.  Tunneling a new
protocol over HTTP does not in any way leverage that, so each
new protocol that's being tunneled has to be secured.  e.g.
each RPC interface carried over HTTP has to be secured
independantly of every other RPC interface.

How are firewalls and their administrators supposed to know the
difference between a secured and an unsecured tunneled-over-HTTP
protocol?  They can't, so we need to give them a way to identify
(so it can be turned off) any SOAP tunneling.

MB

Received on Thursday, 26 July 2001 13:44:50 UTC