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

Note: thread limited to <xml-dist-app> in order to avoid cross posting

>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 "").

More precisely, the field is not optional - it must be there and it
indicates that this is a SOAP HTTP request. That is, it unambiguously
identifies a SOAP HTTP request.

The *value* can be either empty or a URI reference (absolute or
relative). The value is a hint to the HTTP server about what kind of
SOAP HTTP request it is. The server doesn't have to use that hint. It is
up to the server to decide how it wants to use it. It can either make it
very specific or very loose. The important thing is that just as an XML
namespace identifier can't be computed based on the contents, neither
can the SOAPAction header field.

Routing can mean lots of different things including dispatching etc. Wrt
to the role of the SOAPAction header field in HTTP, it has no impact on
the HTTP message exchange whatsoever - what people use it for internally
in their implementations is up to them.

The semantics is as such rather clear - it indicates that this is a SOAP
HTTP request and the service that exports a SOAP endpoint picks a value
that it wants to see as the value. This can either be globally assigned
as is the case for ebXML and others or it can be local depending on the
endpoint and the service.

>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.

It is indeed a hint in that - as you say - if one wants to know the full
message, one has to read the full message. However, this is not what
most HTTP servers want to do - they just want a hint within the HTTP
header field indicating what is going on.

>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.

That would be bad as we then have no mechanism for identifying a SOAP
HTTP request.

> 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.

This means that we have to define what a target object and a method
means for all SOAP requests including event notifications, and purchase
orders. This goes against our goal of staying out of defining a
programming model as much as possible.

In practice, there seems to be no problem in picking a URI for use.
Having it be a resolvable URI and link it to a description of the
service along with a link to a WSDL file are all great uses of the URI
but I don't think we have to mandate this any more than URIs in general
not mandating what they point to.

Henrik

Received on Thursday, 26 April 2001 12:31:45 UTC