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

I believe Henrik's proposed description of SOAPAction is sufficient in
meeting ebXML's planned use now and
in the future.

On a related topic, there have been some discussions in the ebXML community
regarding the use of SOAPAction
to identify an ebXML specific wsdl file. This would enable the recipient of
an ebXML message to quickly/easily
identify a message as "ebXML compliant" while at the same time providing a
high degree of precision as to the
intent of the sending party.

I'm interested in comments, positive or negative, regarding this use of
SOAPAction.


Thanks,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Henrik Frystyk Nielsen
> Sent: Thursday, May 03, 2001 1:04 PM
> To: xml-dist-app@w3.org
> 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 Thursday, 3 May 2001 18:04:02 UTC