XMLP Issues 22 and 95:
Whither SOAPAction

Mark Nottingham

for XML Protocol Working Group Face-to-Face, Rennes, France

Issue 22

There is nothing that says what to do in the HTTP protocol binding if there is a SOAPAction header field but no SOAP in the HTTP request entity body

Issue 95

• Emails expressing confusing over the use of SOAPAction

Purpose of SOAPAction

• SOAPAction is a header specified in the HTTP transport binding which allows two things:
  • the identification of SOAP messages as such
  • the communication of a SOAP message's "intent" - a particular classification of the message
• Additionally,
  • It has been said to be similar to the HTTP method, in that it gives extra context to a message, and more accurately describe the contents therein
  • It aims to expose information to SOAP-unaware devices for their use
  • It aims to expose information to SOAP-aware devices for purposes of performance optimisation
  • It allows services to be grouped logically, or identified as part of a class, independent of their service URIs

At different times, it's been said to be for (or used as)...

• use by firewalls - filtering, imposition of policy at administrative boundry
• dispatch of requests - either to the appropriate node in a cluster, or software component in a server implementation
• identifying the RPC method being accessed
• routing information

Using SOAPAction for security, filtering

• IETF list and Firewall admin/builders lists were polled for validity of this approach:
  • generated hints for filtering is bad; can easily be circumvented
  • it's worse to tell people that the hints can be used for filtering then to not give hints at all, as this is misleading and poor design
  • hints are for best practice, not protocol design' - bdehora@interx.com

Using SOAPAction for dispatch

• URI should be used for dispatch in HTTP servers - 'either you're dispatching on URI or you're breaking the HTTP' (Keith Moore)

Other Comments in Favour

• ebXML uses SOAPAction to identify the message as an ebXML message
• it is useful to have SOAPAction when the request-URI is a message broker service

Other Comments Against

• current implementations use it in bad ways (various)
• may be a solution in search of a problem (Noah)
• barrier to interoperability
• intrudes on SOAP's transport neutrality
• requires use of WSDL, etc.
• separates logic into HTTP server and SOAP processor

Alternatives to SOAPAction

• These are common to most transfer protocols (BEEP, SMTP, HTTP)
  • URL (request-URI)
  • MIME Content-Type

Using Request-URI

• Request-URIs are the Web's mechanism for locating services; they are primarily a routing mechanism in the HTTP.
• Commonly, Request-URIs are used for dispatch in HTTP servers
• This brings the possibility of requiring a one-to-one mapping of services to URIs

Using Content-Type

• Content-Type is MIME's mechanism for hinting; it allows identification of format for dispatch (especially in clients) or for other purposes.
• Using a Content-Type such as 'application/soap+xml' would allow the identification of a SOAP message, but not its intent
• Because Content-Type is already baked into HTTP and MIME, we should have a good reason for using something else for the same purpose.

Proposal One

• Keep SOAPAction, but make it optional, and discourage use for anything except 'intent'
• Insert language instructing on the use of Content-Type for identification
  • Use Content-Type: application/soap+xml for simple SOAP messages
  • Use Content-Type: multipart/related; type=application/soap+xml for SOAP w/Attachments
• Encourage use of URI for dispatch

Proposal Two

• Remove SOAPAction
• Move intent to a top-level attribute in the envelope
• Require use of URI to distinguish services for filtering, dispatch, etc. - one service per URI, when it is necessary to distinguish

Questions for the Working Group

• Is it necessary to identify SOAP messages to HTTP devices? Why/why not?
• Is it necessary to identify the intent of SOAP messages to HTTP devices? Why/why not?
• In either case, is in necessary to always do so?
• If we remove SOAPAction, will it have negative consequences to current deployments?
• If we specify SOAPAction, will there be negative consequences to XML messaging, the Web, etc.?

Secondary Issues

If SOAPAction remains, the following issues need to be considered or clarified:

• should it be available in all MIME-like transports?
• should it be used in both HTTP requests and responses (symmetry)?
• SOAPAction's relationship with intermediaries
• Should it be named 'SOAPAction' - since we're redefining it, is it best to signify this with a new name (e.g., SOAPIntent, Content-Intent, etc.)