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

I'm wondering if it would be worthwhile to take a step back and
examine the entire use of the SOAPAction HTTP header.
I've heard from several people in the XMLP WG that SOAPAction
should _not_ be used for routing, but I'm certain that there are
some SOAP implementations that use it for that exact purpose.
The SOAP spec says that the SOAPAction header is supposed to be
used as an indication of the "intent" of the message but that
can really mean anything (especially when the field is optional -
ie. it can be "").

It seems to me that "intent" is just another way of saying that
its a "hint", so when you want to add text like:
  Often the value of the SOAPAction header field is related to the
  contents of the SOAP Body element but there is no mechanism for
  automatically computing the value based on the SOAP Body element.
it seems to be contradictory.  If SOAPAction is just a "hint"
then the real (fully qualified) "intent" of the message is someplace
else - probably in the Body element.

I'd like to clear up what the "real" purpose of the SOAP Action
Header is supposed to be.  I know its supposed to be for "filtering"
but it seems inconsistent to then not require it to have *any*
relationship to the actual SOAP message itself.  In one of
the XMLP docs (I can't remember which one right now) it talks
about being able to switch between transports, well how does the
SOAPAction get reconstructed when the next transport is HTTP if
there's no relationship between it and the SOAP message itself?

I'd like to propose that we take a different approach and do one
of the following:
 1 - Remove HTTP SOAP Header all together.
     Why is HTTP special - we don't define this type of "intent"
     field for any other transport so why this one?  If people want
     to have an "intent" field then use the HTTP URL.
or
 2 - Keep HTTP Soap Header but define firm rules for its content.
     For example, perhaps something like, its supposed to be the
     Target Object URI and in the RPC case it needs to also
     include the method name.  To me _not_ having a firm rule
     leaves the definition of "intent" too wide open and
     therefore can render it meaningless.

I'd go for the 2nd one, but that's just my $0.02

-Dug

ps.  Ever notice that people will are only willing to pay a "penny
     for your thoughts", but when you offer your opinion it's worth
     twice that.  8-)



"Henrik Frystyk Nielsen" <frystyk@microsoft.com>@w3.org on 04/25/2001
03:09:50 PM

Please respond to <frystyk@microsoft.com>

Sent by:  xml-dist-app-request@w3.org


To:   <xml-dist-app@w3.org>
cc:   <soapbuilders@yahoogroups.com>
Subject:  [i95, i22] - Proposal for clarifying use of SOAPAction




This relates to issue 95 [1] and 22 [2].

Given the recent discussion on soapbuilders and xml-dist-app regarding
the use of SOAPAction header field I propose the following clarification
to the text in the SOAP/1.1 spec. The current text in section 6.1.1 says

     The SOAPAction HTTP request header field can be used to
     indicate the intent of the SOAP HTTP request. The value
     is a URI identifying the intent. SOAP places no restrictions
     on the format or specificity of the URI or that it is
     resolvable. An HTTP client MUST use this header field
     when issuing a SOAP HTTP Request.

          soapaction    = "SOAPAction" ":" [ <"> URI-reference <">
]
          URI-reference = <as defined in RFC 2396 [4]>

     The presence and content of the SOAPAction header field
     can be used by servers such as firewalls to appropriately
     filter SOAP request messages in HTTP. The header field
     value of empty string ("") means that the intent of the
     SOAP message is provided by the HTTP Request-URI. No
     value means that there is no indication of the intent of the
message.

The proposal goes as follows:

* * * * *

The presence of the SOAPAction HTTP request header field indicates that
this is a SOAP HTTP request. The value of the SOAPAction header field is
used to indicate the overall intent of the SOAP HTTP request with the
purpose of providing the recipient with a hint about what the SOAP
message contains:

     soapaction    = "SOAPAction" ":" [ <"> URI-reference <"> ]
     URI-reference = <as defined in RFC 2396 [4]>

An HTTP client MUST use this header field when issuing a SOAP HTTP
Request. An HTTP server MUST NOT process an HTTP request as a SOAP HTTP
request if it does not contain a SOAPAction header field.

If a SOAP HTTP request is required but no SOAPAction header field is
present then the server SHOULD use a 425 (SOAPAction Required) status
code (*).

The value of the SOAPAction header field is a URI-reference as defined
by RFC 2396. The URI can be either absolute or relative. If the
SOAPAction URI is a relative URI, it is interpreted relative to the
Request-URI. The relative URI "" (empty string) indicates that the
SOAPAction URI is the same as the Request-URI. An empty value (without
quotes) means that there is no indication of the intent of the message.

SOAP places no restrictions on the specificity of the URI or that it is
resolvable. However, it is STRONGLY RECOMMENDED that the URI be globally
unique and stable over time.

Often the value of the SOAPAction header field is related to the
contents of the SOAP Body element but there is no mechanism for
automatically computing the value based on the SOAP Body element.

The presence and content of the SOAPAction header field MAY be used by
servers such as firewalls to appropriately filter SOAP HTTP request
messages. It SHOULD NOT be used as an insecure form for access
authentication.

* * * * *

*) We have to check that 425 is free (it is intended as a new status
code). The reason for using a new status code is that there is currently
no mechanism for indicating that SOAP HTTP requests are expected and not
just POST of any old data (including SOAP messages without SOAPAction
header field). There are no existing status codes that cover this case
and SOAP/1.1 is silent on the issue.

Comments?

Henrik

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x95
[2] http://www.w3.org/2000/xp/Group/xmlp-issues#x22

Received on Thursday, 26 April 2001 07:34:23 UTC