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

Henrik,
  I understand your desire to not restrict or mandate how
the SOAPAction header should be use (don't agree yet, but I
understand it 8-)   May people like to use the SOAPAction
header for routing, I believe, because it allows them to
route w/o having to parse the XMLP message, how do you
feel about adding (to the spec or as a well known extension)
an attribute to the SOAP Envelope that contains the routing
information?  This would allow people to route with the
minimal about of parsing but still preserve the openness
of the SOAPAction header.
Others - would this limited parsing still be too much?
-Dug


"Henrik Frystyk Nielsen" <frystyk@microsoft.com>@w3.org on 05/03/2001
02:04:23 PM

Please respond to <frystyk@microsoft.com>

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


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




As promised here is an updated revision of the text for the SOAPAction
header field which I hope incorporate the feedback from the first
proposal [1] addressing issues 22 [3] and 95 [4]

Note that the purpose is *not* to break existing applications but to
clarify its use - the text is in accordance with the spirit of SOAP/1.1
but it does clarify  some of the edge cases.

Comments are welcome - especially if they are specific regarding the
proposed wording :)

* * * * * * * * * * * * * *

The presence of the SOAPAction HTTP request header field indicates that
this is a SOAP HTTP request, which means that it contains a SOAP message
intended for a SOAP processor. The value of the SOAPAction header field
is used to indicate the intent of the SOAP HTTP request in a manner
readily accessible to the HTTP server.

     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 the request-URI identifies a SOAP resource that requires the use of a
SOAP HTTP request but no SOAPAction header field is present then the
server SHOULD respond with a 427 (SOAPAction Required) status code. (*)

If a HTTP request contains a SOAPAction header but the HTTP entity body
is empty or contains a malformed SOAP message then the server SHOULD
return SOAP Client fault message.

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.

Although the purpose of the SOAPAction header field value is to indicate
the intent of the SOAP message there is no mechanism for automatically
computing the value based on the SOAP envelope. In other words, the
value has to be determined out of band similar to MIME media types.

It is recommended that the same value be used to identify sets of
message types that are logically connected in some manner, for example
belonging to the same WebService. It is STRONGLY RECOMMENDED that the
URI be globally unique and stable over time.

The presence and content of the SOAPAction header field MAY be used by
servers such as firewalls to appropriately filter SOAP HTTP request
messages and it may be used by servers to facilitate dispatching of SOAP
messages to internal message handlers etc. It SHOULD NOT be used as an
insecure form of access authorization.

* * * * * * * * * * * * * *

*) 427 seems to be the next available status code according to [2]

Henrik

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0142.html
[2] http://www.iana.org/assignments/http-status-codes
[3] http://www.w3.org/2000/xp/Group/xmlp-issues#x22
[4] http://www.w3.org/2000/xp/Group/xmlp-issues#x95

Received on Friday, 4 May 2001 10:17:51 UTC