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.
Cheers,
Chris
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