- From: <Noah_Mendelsohn@lotus.com>
- Date: Tue, 1 May 2001 15:05:42 -0400
- To: xml-dist-app@w3.org
A few thoughts. First, some things I recall being discussed while SOAP 1.1 was being hatched: 1. The general reason for having a SOAPAction is because we suspect that firewalls and other security mechanisms will want an easy way to reject unwanted SOAP traffic without having to go to the (presumably) considerable expense of cracking the XML itself. 2. The reason for having a string (URI) value as opposed to just an IsSOAP flag is the perception that it's desireable to know at least something about the specific sort of SOAP message, also without having to crack the XML. I don't think we can limit what a given server will do with this information, however... 3. ...as has been noted, the information is just a hint. Servers and firewalls need to conspire with each other (and to some extent trust each other) to implement required levels of security. Specifically, we anticipated that firewalls, for example, would do preliminary filtering based on SOAPAction, but _the server or application that cracked the XML would be responsible for verifying (in some unspecified manner) that the SOAPAction URI was indeed consistent with the contents of the envelope (in many cases, this will specifically be with the BODY, but remember that the BODY is just an alias for an anonymously routed HEADER in the non-RPC case.) This checking is needed in many cases that a malicious message doesn't first pass a firewall with a misleading SOAPAction, then do something unintended. 4. SOAPAction is currently defined only for the specific HTTP binding provided by the specification. Some other thoughts and tentative conclusions: A. It seems to me that we should establish a rule or guideline that all information derivable from the SOAPAction URI also be derivable from the contents of the Envelope itself. This ensures that the SOAPAction field is indeed a hint, and that any use of it (as opposed to use of the envelope) is indeed (a) just an optimization per point #2, and (b) can indeed be cost checked per #3. B. As Doug and others have pointed out, having a fixed mapping from the contents to the SOAPAction ensures that (a) SOAPActions can be generated automatically and therefore (b) can be automatically provided when an SMTP message transitions to HTTP. Lacking such a standard mapping means that any description of a SOAP service (e.g. WSDL) must include not just a description of the envelope, but also mechanisms for managing SOAPAction. It also suggests a lack of ability to share code at the receiving end to do the check of #3. On the other hand, Henrik is right that particularly in the non-RPC case, we lack a fixed convention for mapping an envelope into an action---maybe I'm sending you a purchase order because I want you to order something, or maybe I'm sending it to a filesystem for filing. So, I see this as a tradeoff that requires a bit more discussion. C. I think it's useful to view SOAPAction as an artifact of a particular binding, in this case HTTP. Other bindings, including others running over HTTP, might or might not use similar mechanisms. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Tuesday, 1 May 2001 22:59:59 UTC