Re: A tale of two bindings

On Thu, Jul 26, 2001 at 09:33:43AM -0400, Mark Baker wrote:
> > > 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.

4xx or 5xx status codes may be generated by software other than the
SOAP processor; either the HTTP implementation of the sender, or an
HTTP intermediary.


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

Exactly - and that action may be based on false assumptions.


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

Turn it around - an HTTP implementation that isn't aware of SOAP
semantics may make assumptions based on the status code of the
message. 


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

I still don't know what this means.


> [...] we need to give them a way to identify (so it can be turned
> off) any SOAP tunneling.

Content-Type. Of course, there are no guarantees that all SOAP-like
messages sent by HTTP are flagged as such, but that's not our problem
- it's a problem with filtering based on hints and heuristics in
general.


-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 26 July 2001 16:02:50 UTC