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 Wednesday, 29 August 2001 14:18:13 UTC