Re: SOAP and entities.
Noah Mendelsohn <[email protected]> Thu, 17 Oct 2002 14:33:53 -0400
| Newsgroups | gmane.comp.windows.devel.soap.general |
|---|---|
| Message-ID | <[email protected]> |
Doug Ransom asks: >> I do not understand the the motivation of >> not allowing DOCTYPES in SOAP messages. I can't speak for the workgroup, or the authors of pre-SOAP 1.1 specs, in which I did not participate. My view is: SOAP is a quite specialized application of XML, specifically for messaging. To be successful in the marketplace, SOAP must be moderately competitive with other high performance messaging technologies, such as EDI, Corba, etc., many of which use binary formats. The variable offset text format of XML is already a strike against it from a performance point of view, but is compelling for other reasons. Adding DTDs would be perfectly coherent, but would add yet more to the processing burden. Just try to build a system that handles thousands of messages per second on a commodity processor and you'll find that all the buffer management needed to do the string substitution implied by entities is a significant burden. The value does not seem, to me, to be worth the cost. Also, and I can't say for sure that anyone considered this, there are some denial of service attacks that are possible using entities. These particular attacks to away if you don't allow them (though, even with entities, you could find ways to limit the damage -- e.g., decline to allow substitutions that grow the message by more than N times in size). BTW: built in XML references such as < can and should be used for their intended purpose in SOAP messages. Hope this helps. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------ You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other DevelopMentor lists at http://discuss.develop.com.