1 / 4

SOAPAction

SOAPAction. At F2F in Dinard we narrowed the choice down to: Use of SOAPActon is discouraged. SOAPAction is an optional part of SOAP, supported by not required. Services MAY require SOAPAction and any software wishing to access those services MUST be able to send it.

jimmyt
Download Presentation

SOAPAction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SOAPAction • At F2F in Dinard we narrowed the choice down to: • Use of SOAPActon is discouraged. SOAPAction is an optional part of SOAP, supported by not required. Services MAY require SOAPAction and any software wishing to access those services MUST be able to send it. • 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.

  2. SOAPAction • A proposal: • 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. • Still need additional text to define ‘intent’.

  3. SOAPAction • Mark Nottingham wants more explicit text stating that: • SOAPAction should not be generated or required, UNLESS there is a particular purpose for it. • Larry Masinter would like the one of two choices: • A document that states exactly what SOAPAction is and how it should be set. Remove any vagueness from it. • Disallow SOAPAction all together. • Stuart Williams points out that it isn’t defined who it is ‘optional’ for: • People deploying a Web Service? • People designing/developing a Web Service? • People designing/developing a (generic) Web Services Platform? • People designing/developing a (generic) Web Services Client platform? • Henrik stated that the ‘optional’ lies in whether the service provider wants to use or not.

  4. SOAPAction Mark Nottingham came up with a new draft proposal: Previous versions of SOAP required the SOAPAction HTTP request header to be present when the HTTP binding was in use; in this binding, SOAPAction is OPTIONAL. SOAPAction is designed as an optimisation mechanism to convey the 'intent' of a SOAP message bound to a HTTP request. SOAP Applications using this binding MAY require the presence of a SOAPAction HTTP request header. However, SOAPAction SHOULD NOT be generated or required by SOAP implementations UNLESS a particular SOAP Application invokes this functionality. It is RECOMMENDED that SOAP Applications which do so formally express their requirements through some form of service description.

More Related