W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2001

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

From: Doug Davis <dug@us.ibm.com>
Date: Thu, 26 Apr 2001 13:49:16 -0400 (EDT)
To: xml-dist-app-request@w3.org
Message-ID: <OFF419F39D.0A9D143C-ON85256A3A.005D15D6@raleigh.ibm.com >
>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.

That's one of the problems with it - if it can't be computed based on
the contents then how should it be produced when you go from SMTP
to HTTP?

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

But again, isn't this part of problem.  The SOAP spec doesn't really say
anything about how it should be used (expect "possibly" to filter things).
So here we have a field that can be empty or it can contain something
and it can be used to filter or it can be used to dispatch or it can
be used to route or it can be ignored.  This doesn't sound like the
SOAP spec really says much about it - other than it must be there for
HTTP.  To me if a field must be there then there must be a clear
definition of what its value should be and how it should be used.

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

I guess I'm wondering why it matters?  Unless I'm mistaken a JSP, cgi-bin,
servlet... don't require a special header indicating what type of request
it is, so why does SOAP?

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

So, I'm wondering why is SOAP special?  Why doesn't JSP need this
hint?  I believe filtering will probably be done on SOAP requests
the same way they're done on JSPs (ie. maybe by url or something else).

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

I'm not sure how I ended up here (I was in favor of #2), but now I'm
beginning to question the entire need for the header.  Perhaps someone
could elaborate on the exact problem it was trying to solve any why
other HTTP requests (like jsp, servlets...) don't have that problem?

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

Actually, that's why I would prefer if it were just the Target Object
URI even in the RPC case - but I know some implementations are sticking
the method name in there too.  We have to have a target object uri
for all soap messages don't we?  (I guess this could lead to the
discussion about whether you must have at least one body element -
but in that case a "" SOAPAction fits).  So, if there is a well
defined Target Object URI for *all* soap messages, why not just
make that the SOAPAction header?

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

The problem with not coming up with a more clear definition is that
it doesn't solve the problem with the current SOAP spec.  To me
the fact that there is so much discussion about the SOAPAction header
is a sign that we need to do more than just reword the description
of it - our goal should be to remove the need for this discussion
again after the XMLP spec is produced.

Received on Friday, 27 April 2001 05:36:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:13 UTC