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

Re: XML Protocol: Proposals to address SOAPAction header

From: christopher ferris <chris.ferris@east.sun.com>
Date: Mon, 11 Jun 2001 11:36:27 -0400
Message-ID: <3B24E57B.262D7F30@east.sun.com>
To: Dave Winer <dave@userland.com>
CC: "Williams, Stuart" <skw@hplb.hpl.hp.com>, Larry Masinter <LMM@acm.org>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Simon Fell <soap@zaks.demon.co.uk>, xml-dist-app@w3.org, xmlp-comments@w3.org
These are, IMHO precisely the reasons why SOAPAction
should be deprecated. SOAPAction cannot be considered
part of the SOAP protocol since its use is only specific
to the HTTP binding. Yet, SOAP is intended to be
transport protocol independent. I should be able to
plug into my SOAP processor, any transport protcol
I choose without having to jump through any hoops.

I can think of any number of valid use cases where
there would in fact be more than one transport protocol
at play between two (or more) SOAP applications including
some manner of enterprise middleware (JMS, whatever) a
firewall proxy server, intermediaries in the form of
marketplace service providers, etc. 

Building a protocol that is guaranteed to break in
this case seems like a non-starter. The SOAP protocol
must be (IMHO) completely transport protocol independent
or it is useless in the long run.

If there were some source of information within the 
SOAP:Envelope that could be used to populate a special
header for some particular transport protocol binding,
that would be a different story altogether. But, since there
isn't, SOAPAction should be deprecated. 



Dave Winer wrote:
> I think I can resolve both of these problems.
> 1. When not going through HTTP there is no SOAPAction header. Therefore you
> can't use it if you're not going over HTTP, and can use it if you are.
> 2. If an intermediary doesn't pass the SOAPAction header when going through
> HTTP, it will break the application at the end (or in the middle) who
> depends on the SOAPAction header.
> There you go. These are not reasons to say goodbye to SOAPAction. They're
> just things to be aware of if you're building an application that goes over
> transports other than HTTP or uses an intermediary that is not
> SOAPAction-friendly. (BTW, I'm not sure there are any intermediaries at this
> time, so this could be added as a caveat for future intermediaries -- please
> pass on the SOAPAction header.)
> Have a great day one and all!!
> Dave
Received on Monday, 11 June 2001 11:38:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:36 UTC