Your message stated *most* SOAP implementations are vulnerable, seeming
to indicate that implementors could make decisions to protect against
this vulnerability.
Yes. Unfortunately, the answer is "don't use an XML parser" -- they have
to restrict it to a specific subset of XML, which IMHO defeats the purpose
of using XML marshalling in the first place.
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.
Right, buzzword conservation seems to be the primary goal. Bit conservation
damn well better be a goal of OPES. Screwing around with inefficient RPC
syntaxes is an application choice. Doing that within an intermediary is
suicidal.
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.
Yes, that was the answer given at the time. And it made a certain degree
of sense if you assume that iCAP services would be implemented by people
who don't understand protocols. I don't think that ever happened either.
In any case, that design goal was abandoned as soon as iCAP chunking
failed to comply with HTTP message parsing rules.
My problem is that people look at HTTP and, seeing how incredibly verbose
that protocol is, they assume that it won't hurt to be just as verbose with
other protcols, or even add more verbosity/complexity by adding XML. But
HTTP was designed for the Web, and the Web has a specific component
interaction profile that HTTP was designed to exploit. There is no way
that I would ever use HTTP syntax for something like RPC, which is
dominated by small-grain control messages rather than large streams.
I'd rather use raw XML over TCP for that type of application, though
if I were designing it from scratch I would use a self-descriptive
grammar that was length-delimited, rather than a character-delimited syntax
like XML. In fact, that's exactly what I am doing for the waka protocol.
....Roy