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

From the ebXML perspective SOAPAction is used primarily for identification
and dispatching
functions. The current ebXML message service spec sets the SOAPAction to a
static
value of "ebXML". This "label" offers some "hint" of the message payload
which
provides "generic message brokers" the information they need to dispatch
message
processing to the proper handler. One potential issue with ebXML's current
use of
SOAPAction is the use of a "relative path" URI (e.g. "ebXML"), which raises
the
potential for different interpretations and this could impact
interoperability.

The SOAPAction would have real value if it conveyed unambiguous intent and
consistent
semantics so that those requesting services and those providing services
have the
same understanding. One possible way to achieve this is to use the
SOAPAction to identify
a WSDL file that defines the service being called. This would allow the use
of locally
scoped services to use absolute or relative path URI's and globally scoped
services
could define a universal constant(e.g.
http://registry.ebxml.org/service/messageservice.wsdl)
that a message broker can use to perform dispatching.

I'm very interested in knowing what people think of this proposed use of
SOAPAction, before I make
any proposals to the ebXML TR&P team.

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: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Thursday, April 26, 2001 6:33 AM
> To: frystyk@microsoft.com
> Cc: xml-dist-app@w3.org; soapbuilders@yahoogroups.com
> Subject: [soapbuilders] 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
>
>
>
>
> To unsubscribe from this group, send an email to:
> soapbuilders-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Received on Thursday, 26 April 2001 11:53:03 UTC