Roy T. Fielding wrote:
XML is not 8bit clean, and
therefore is not suitable for encapsulating arbitrary content within
an application that operates at router speeds. That's also why most
SOAP implementations are vulnerable to denial-of-service attacks
simply by selective abuse of the XML data.
If you believe this to be the case, please raise this as an issue with
the XML Protocol WG on xml-dist-app(_at_)w3(_dot_)org(_dot_)
It is a very well known fact of XML. But since the XML Protocol WG is,
by definition, restricting themselves to a buzzword-compliant syntax
rather than one chosen for its protocol capabilities, there really isn
any point in notifying them.
Your message stated *most* SOAP implementations are vulnerable, seeming
to indicate that implementors could make decisions to protect against
this vulnerability.
I have trouble believing that iCAP justifies the overhead of an HTTP
syntax, let alone XML on top of HTTP.
I'd point out that SOAP is not bound to the HTTP; that is just the first
binding, and I see signficant numbers of people wanting to move away
from it. Also, SOAP isn't intended for arbitrary data; that's what SOAP
w/ attachments and DIME (for example) are for. They aren't really good
solutions for the problem iCAP attempts to address, but they should be
noted.
They are very recent and untried, though I agree that the purpose of them
is to enable encapsulation. I prefer TCP for that, or SCP if there is a
need for mutiplexing across a single connection. Layering application
protocols is a waste of bits.
Perhaps bit conservation isn't the foremost goal to be considered for
the target applications of SOAP.
Just to be clear, when I was first introduced to iCAP (September 1999),
the first comment I had was that it didn't make sense to use HTTP for
this purpose. I didn't think that anyone would want to do iCAP across an
Internet connection (as opposed to a LAN between the iCAP client and
iCAP server), so UDP or reliable ordered multicast would have been my
design choice.
I believe that a large part of the motivation for attempting to use HTTP
was to allow implementations (on both ends) to use existing HTTP stacks,
rather than coding and testing completely new stacks for
whatever-over-UDP-or-multicast. Whether or not this was a good decision
depends mostly on the climate around iCAP adoption, etc.
--
Mark Nottingham
http://www.mnot.net/