Re: SOAP's prohibiting use of XML internal subset

noah_mendelsohn@us.ibm.com wrote:

> The fact is that there are advantages as well as disadvantages to SOAP's
> decision to disallow the internal subset, and as one who has built SOAP
> implementations I can tell you that the performance implications of
> dealing with the internal subset would be significant for the sorts of
> applications and performance regimes that my employer (IBM) anticipates.
> General purpose XML processors are only sometimes the right design point
> for consumers of XML.  Try handling hundreds or thousands of messages per
> second while doing all the dynamic buffer management implied by parsing
> internal subsets and doing entity substitution and you will find that
> there is a real cost to allowing it.  There are also some denial of
> service attacks that are possible with entities, though presumably
> heuristics can be used to limit their impact. 

I can certainly see this point; I'll check the SOAP specs - if what they 
say is "thou shalt not produce an internal subset", that seems more 
defensible than saying "consumers must throw mesages on the floor if 
there's an internal subset".

Also it's been pointed out that the use of the internal subset upens up 
the potential of the old "billion laughs" denial-of-service attack. 
Ouch.  If I were feeling self-aggrandizing I'd point once again at 
XML-SW, which if it had any official standing is exactly what SOAP 
(among other people) need.

With respect to Paul's original point, I don't think the i18n 
char-entity issue is really material here; the content of a SOAP 
envelope is being generated by a machine, which can blast the binary 
code-points straight into the UTF-whatever stream or do numeric 
character references. -Tim

Received on Tuesday, 26 November 2002 00:07:11 UTC