W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2001

RE: [i95, i22] - Proposal for clarifying use of SOAPAction

From: <Noah_Mendelsohn@lotus.com>
Date: Tue, 1 May 2001 15:05:42 -0400
To: xml-dist-app@w3.org
Message-ID: <OF696B7BEC.7F2F9BF5-ON85256A3F.00675B5A@lotus.com>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:13 UTC