[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
<snip/>
> 2. SOAP lies. HTTP is an application protocol, not a
> transport protocol.
> It has syntax and semantics, just as XML has syntax and semantics.
> Imagine if someone asked you to submit a purchase order in some ebxml
> schema and you generate a valid instance but you actually put
> all of the
> "real" information in comments. The PO stuff is just 0's and empty
> fields. And maybe you've done this because you've colluded
> with someone
> on the "inside" to send the information this way instead of
> the regular
> way. They told you that if you sneak it through in this way
> then it will
> bypass the company's screening and business logic and they'll
> make sure
> it gets approved at whatever price. This is what SOAP does to
> firewalls.
> It lies to them. It says: "I'm HTTP traffic. I'm doing a
> POST. Check the
> HTTP specification to know what that means." Jabber, BEEP and
> many other
> XML protocols do not do this. They are defined at the TCP level as is
> logical. Routing SOAP over HTTP is a way for someone inside
> the company
> and someone outside the company to collude to disable the
> RPC-filtering
> features of the service.
>
> SOAP lies both about what it is doing (POST to do getStockQuote) but
> what it is working with. "Ignore the component behind the curtain. It
> isn't working with millions of resources that really should have URIs.
> It's just one resource. One big fat honking resource. Really." If SOAP
> ran on TCP it would not need to feel obliged to obey the rules of the
> Web and HTTP. But it doesn't.
Personally, I think you make valid points. What I take issue with is the
notion that SOAP has introduced something fundamentally new into the mix. I
still think the focus on RPC misses the point. It's still just XML over
HTTP, and I don't see how the RPC approach to SOAP is really fundamentally
different from the applications developers are doing that accept HTML form
posts. In fact, with existing tools its easier for me to expose logic via an
HTTP post using HTML forms than it is for me to use SOAP, and I'm hiding
things just as much as with SOAP. I fail to see how pointy brackets vs.
name/value pairs poses an inherent new security risk. You can use either to
invoke logic behind the firewall.
SOAP-RPC seems to me to just be building upon the approach toward building
web systems that started with CGIs. I don't see SOAP as having introduced
anything fundamentally new into the mix in this regard. I've found this
whole REST debate to be interesting and enlightening. I feel those of us
building web apps could learn quite a bit from REST. What I don't see is why
some folks are picking on SOAP so much and suggesting that this is somehow
intrinsically worse than all of those CGI programs out there accepting a
bunch of form posts through one big fat honking resource -- all with content
that is just "application/x-www-urlencoded" or "multipart/form-data". That I
don't understand. Developers are left with the impression from Bruce
Shneier's criticism (and that of others) that there is something
fundamentally new about SOAP that poses greater security risks to the
network. The truth is that the issues with SOAP are the same issues that
have been there since the very first CGI script was written. I've heard
nothing, yet, to convince me otherwise.
On the other hand, if the criticism is simply over vendors failing to put
enough emphasis on security issues, I don't disagree. The vendor push behind
SOAP is pouring gasoline on the fire with regard to pervasive security
problems in software today. But I don't see anything inherent in SOAP that
is making things worse than they already are.
|
