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

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

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 7 May 2001 07:57:39 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D0297CBDE@red-msg-07.redmond.corp.microsoft.com>
To: "Jeffrey Kay" <jkay@ENGENIA.COM>, "Dick Brooks" <dick@8760.com>, "Martin Gudgin" <marting@develop.com>, "Jake Savin" <jake@userland.com>, "Painter, Philip" <Philip.Painter@compaq.com>, "Daniel Barclay" <Daniel.Barclay@digitalfocus.com>
Cc: <xml-dist-app@w3.org>

>So this is one of the more fascinating issues to me in SOAP.  
>I'm in the "anti" category for the SOAPAction.  I consider it 
>at best a duplication of what the URI should be.

If I may direct the attention at the proposed wording then this is
absolutely not what it says

	
http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0053.html

>Overall, I'd like to see the SOAPAction header just go away.  
>I've heard arguments that it's necessary for SOAP 
>intermediaries, but I'm not certain I buy that either.  If an 
>XMLP intermediary must understand the SOAPAction header, then 
>it's next stop is to process some amount of the XML encoded 
>within the message.

No, there is no assumption that this is the case. One can claim that
many of the "content-*" header fields are redundant: Take the content
type which one might be able to figure out by sniffing the contents.

However, this is not the point - the point is for an HTTP application
that only deals in HTTP header fields, request methods, and status codes
to be able to figure out what is going on without having to dive into
XML or other languages.

In that sense, SOAPAction provides a mechanism that allows HTTP servers
and client to indicate their intent and to describe the contents of a
message. This is in my mind a Good Thing (tm).

Henrik
Received on Monday, 7 May 2001 11:37:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:01 GMT