Re: SOAPAction Proposal

I'm not sure we should do that.  If SOAPAction becomes just
like all other user-defined HTTP headers then should we really
be picking on it?  We don't say "don't send a FOO header unless
there is a particular purpose for it", so I'm not sure we should
for SOAPAction.  I must admit though, I do see your point but I
I just want to try to remove any "specialness" from SOAPAction
and I'm afraid that requiring it or mandating when it should
_not_ be used continues to give it some sort of special status.
-Dug


Mark Nottingham <mnot@mnot.net>@w3.org on 08/29/2001 02:18:12 PM

Sent by:  xml-dist-app-request@w3.org


To:   Doug Davis/Raleigh/IBM@IBMUS
cc:   xml-dist-app@w3.org
Subject:  Re: SOAPAction Proposal




I like the general direction of this. However, this proposal seems to
lose something that was more explicit in both of the previous
proposals; that, by default, SOAPAction should not be generated or
required, UNLESS there is a particular purpose for it.

Cheers,



On Wed, Aug 29, 2001 at 11:11:54AM -0400, Doug Davis wrote:
> All,
> Right now the SOAPAction issue is a choice between:
>   1 - Use of SOAPAction is discouraged. SOAPAction is an optional
>       part of SOAP, supported but not required. Services MAY
>       require SOAPAction and any software wishing to access those
>       services MUST be able to send it.
>   2 - Use of SOAPAction is deprecated. Senders SHOULD NOT send
>       SOAPAction.  Receivers MUST NOT accept or reject messages
>       on the basis of the presence, absence, or value of the
>       SOAPAction header.
>
> Looking at these two choices it seems like we really are actually
> very close to an agreement.  IMO, they're actually (almost) the same.
> Here's why: if we start with option #2 (aka kill SOAPAction) a Web
> service can require any HTTP header be sent - and it is free to
> reject the request if it is not sent.  So, given that, if the WG
> decides that it doesn't like SOAPAction anymore and its use is
> "deprecated" or "discouraged" then what we're really saying is
> that we should say nothing about it - as if it never existed.  And,
> if it never existed then people should be free to require/use any
> application-defined HTTP they want - including one that just
> happens to be named "SOAPAction".  This sounds a lot like option #1.
> So I guess my formal proposal would be to have the spec say
> something along the lines of:
>
>   SOAP no longer requires the SOAPAction HTTP header.  While the
>   definition of, or a Web services requirement of a SOAPAction header,
>   as with any application-defined HTTP header, is left as an
>   implementation choice and is outside the scope of this specification,
>   a suggested usage of the SOAPAction header is that it can be used
>   to indicate the "intent" of the XMLP/SOAP HTTP request.
>
> (Editors will obviously need to fix it up, and we should probably
> expand a little on what "intent" means but it's a start)
> This seems like it should make the "kill SOAPAction" people happy
> because it is no longer required, but should also make the people
> who use SOAPAction (and see its value) happy because they can
> still use it and provides for a "suggested" usage.
> Thoughts?
>
> -Dug
>

--
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 4 September 2001 07:28:33 UTC