RE: [i95, i22] - Proposal for clarifying use of SOAPAction

Henrik --

> Remember that SOAP is a protocol - it is not a server API which makes
> SOAP fundamentally different from CGI-scripts, server 
> modules, servlets
> etc. Comparing SOAP to CGI scripts makes no sense - it would be
> perfectly legitimate to implement a SOAP processor as a CGI 
> script. This
> has already been brought up on this thread [10].

This again raises problems.  I understand that we want to think of SOAP as a
wire protocol, but that still makes the SOAPAction header inconvenient.
Essentially, the HTTP binding with the SOAPAction header further qualifies
the nature of the content carried over HTTP, but this should be completely
unnecessary since HTTP is already well suited for submitting requests and
receiving responses.  Look at this from a minimalist perspective -- if the
SOAPAction header isn't there and the semantics for a 500 error response are
unloaded, how would that cause problems in SOAP? It wouldn't cause any as
best as I can tell.  
 
> HTTP GET requests have the property that *all* parameters are 
> expressed
> either as part of the URI (after the "?" mark) or within the 
> HTTP header
> fields. The semantics of GET is not application based - GET is defined
> by HTTP to mean something very specific namely "give me a 
> representation
> of yourself". 

In RFC1945 [http://www.ietf.org/rfc/rfc1945.txt], GET is defined as follows:

   The GET method means retrieve whatever information (in the form of an
   entity) is identified by the Request-URI. If the Request-URI refers
   to a data-producing process, it is the produced data which shall be
   returned as the entity in the response and not the source text of the
   process, unless that text happens to be the output of the process.

If we imagined that GET could be used with SOAP, then the SOAP process would
be the data-producing process that would return the produced data in the
above definition.  

> The definition of POST is slightly more complex. What SOAP effectively
> does is to provide a useful mechanism for describing parameters in XML
> rather than in HTTP header fields but as it is still an HTTP 
> request, we
> have to follow HTTP semantics.
> 
> Note btw that SOAP doesn't require that SOAP requests are followed by
> responses - the HTTP binding in SOAP says nothing like that.

However, we look at SOAP as a POST process, defined as follows:


   The POST method is used to request that the destination server accept
   the entity enclosed in the request as a new subordinate of the
   resource identified by the Request-URI in the Request-Line. POST is
   designed to allow a uniform method to cover the following functions:

      o Annotation of existing resources;
      o Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;
      o Providing a block of data, such as the result of submitting a
        form [3], to a data-handling process;
      o Extending a database through an append operation.

[I must admit that it feels sort of funny that I'm quoting RFC1945 since
Henrik is one of the authors -- therefore I know I'm preaching to the choir,
right?]

So using the POST method definition (3), SOAP would be the block of data to
be submitted to a data handling process, a SOAP processor, which would
return something appropriate.  The semantics of POST aren't violated by
SOAP, so again I'm not sure what problem the SOAPAction header solves (or
the use of the 500 error code for that matter).  

And that's really the point, right?  We have endeavored to define XMLP
independent of HTTP (and other protocols) in our requirements document.  We
presume that a protocol binding allows us to actually ship SOAP/XMLP from
one point to another, whether that be straight TCP sockets or HTTP or SMTP.
That being the case, why does SOAP/XMLP require information to be surfaced
into a carrier protocol like HTTP?  Shouldn't we just define the HTTP
semantics to follow when using SOAP/XMLP rather than defining new error
codes and new headers?  We could easily state that the URL in an HTTP POST
defines an endpoint where a SOAP message is expect to land.  The response is
a 200 (message accepted, here's the response), 204 (message accepted, no
response needed), 401 (message can't be processed), 404 (no SOAP processing
here), 500 (bad SOAP message).  We could argue about 404 v. 500, but I think
you get the point.

I'd augment this with a SOAP/XMLP MIME-type that clearly identifies the
contents of the POST as a SOAP message.  We might want two MIME-types, one
for a request and one for a response.  As a result, I'm not sure where the
SOAPAction header adds value.  In the case of the Frontier implementation,
the SOAPAction header could be just as easily restated as a URI.  Where do
you see the SOAPAction header adding value?
 
jeffrey kay <jkay@engenia.com>
chief technology officer, engenia software, inc. 
"first get your facts, then you can distort them at your leisure" -- mark
twain 
"golf is an endless series of tragedies obscured by the occasional miracle"
-- sports illustrated 
"if A equals success, then the formula is A equals X plus Y plus Z. X is
work. Y is play. Z is keep your mouth shut." -- albert einstein

Received on Monday, 7 May 2001 16:25:25 UTC