Re: SOAPAction Proposal

Personally, whether we choose those exact fields from the
SOAP-Env or not, I agree with this type of approach for a couple
of reasons:
 - it removes the ambiguity of the SOAPAction header.  Right
   now its so open-ended and being used in so many different
   ways that its making interop harder than it needs to be
 - it helps implementators that need (or just want) to get the
   routing information as soon as possible, including w/o
   opening the SOAP Envelope.
 - it allows for increased security/reliability but forcing
   the SOAPAction to match something inside the envelope
 - it allows for easily switching between transports since
   the header can now be regenerated in a consistent way

-Dug


"Martin Gudgin" <marting@develop.com>@w3.org on 05/03/2001 05:06:55 AM

Sent by:  xml-dist-app-request@w3.org


To:   "XML Protocol Comments" <xml-dist-app@w3.org>
cc:
Subject:  SOAPAction Proposal



I've been reading the mails on SOAPAction, there seems to be some sentiment
for the idea that the value of SOAPAction should reflect some information
in
the body of the message. Here is a proposal for discussion;

The value of SOAPAction *must* be the namespace URI and local name of the
first element child of soap:Body separated by a #. If the value of
SOAPAction does not contain that value the server *must* generate a fault.

e.g.

POST someuri HTTP/1.1
Content-Type: text/xml
Content-Length: nnnn
SOAPAction: myuri#myelement

<soap:Envelope xmlns:soap='uri for soap' >
  <soap:Body>
    <m:myelement xmlns:m='myuri' />
  </soap:Body>
</soap:Envelope>

Note that currently SOAPAction can be anything, it doesn't need to reflect
any piece of information in the body of the message. This proposal is
similar ( if not identical... ) to the SOAPMethodName in SOAP 1.0[1]

Flames, comments etc. to the usual address,

Martin Gudgin
DevelopMentor

[1] http://www.soaprpc.com/mirror/ietf/draft-box-http-soap-01.txt.html

Received on Thursday, 3 May 2001 07:38:39 UTC