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

Henrik --

> >So this is one of the more fascinating issues to me in SOAP.  
> >I'm in the "anti" category for the SOAPAction.  I consider it 
> >at best a duplication of what the URI should be.
> 
> If I may direct the attention at the proposed wording then this is
> absolutely not what it says
> 	
> http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0053.html
> 
> >Overall, I'd like to see the SOAPAction header just go away.  
> >I've heard arguments that it's necessary for SOAP 
> >intermediaries, but I'm not certain I buy that either.  If an 
> >XMLP intermediary must understand the SOAPAction header, then 
> >it's next stop is to process some amount of the XML encoded 
> >within the message.

I know what the wording says.  The wording specifically indicates that if
the SOAPAction header isn't there then the HTTP server must not process a
request as a SOAP request.  The funny thing about this is that HTTP makes a
basic assumption that an inbound request is going to an appropriate
receiver.  (You know, I've read this sentence a couple of times and I'm not
sure it's clear enough.)  I make an HTTP GET to a URI and I expect something
back.  The semantics of that exchange are application based.  GETs retrieve
responses, and it's up to the application to understand what the expected
response is going to be.  The only hint that is supplied is the MIME type,
which clues the browser as to how it should render the content.  The
SOAPAction header argument seems to presume that I might accidentally POST a
SOAP message to a URI and the web server would look at the message (with the
SOAPAction header) and fail because it wasn't a URI that would accept SOAP
messages.  As an application developer or builder, how could that happen?
Why would a SOAP message be posted to a URI where a SOAP response wasn't
expected?  If I POSTed a request to a CGI on a web server where none
existed, the transaction would fail, as expected.  Why should SOAP get any
different treatment?  That's the part I don't get.  If a failure response
code is returned, then the SOAP message failed.  If the problem is that
we're overloading the HTTP failure responses by providing another special
SOAP failure code (indicating that a SOAP message was incorrectly directed
to an inappropriate URI), then that's the problem to fix -- make it so that
SOAP conforms to the expectations of HTTP and the web and not use well known
HTTP error codes to mean something else.
 
> No, there is no assumption that this is the case. One can claim that
> many of the "content-*" header fields are redundant: Take the content
> type which one might be able to figure out by sniffing the contents.
> 
> However, this is not the point - the point is for an HTTP application
> that only deals in HTTP header fields, request methods, and 
> status codes
> to be able to figure out what is going on without having to dive into
> XML or other languages.
> 
> In that sense, SOAPAction provides a mechanism that allows 
> HTTP servers
> and client to indicate their intent and to describe the contents of a
> message. This is in my mind a Good Thing (tm).

In this sense, this is A Bad Thing (tm) :-).  HTTP applications deal with
headers, error codes, and request methods that are HTTP conformant.
Essentially we're extending HTTP to cover some cases that HTTP doesn't
really need to cover.  A URI is a perfectly well understood and standard way
of identifying resources on the web.  The nature of the request is
fundamentally identified by what happens when the URI is called (CGI call,
page retrieval, etc.).  If a given URI understands SOAP, then it can process
it accordingly.  If we decide that we want to add a MIME-type for SOAP
messages, then that's one extra hint (just like the cgi-encoded MIME-type)
that tells the recipient URI what to do.  But a SOAPAction header is
absolutely not necessary to determine how to handle the request.  That's
like indicating that you need an extra header to POST arguments for a CGI
call -- you don't in that case and I'm not seeing why we think this is any
different.

The only thing that could be an issue is the HTTP 500 response, which is
used to indicate a SOAP fault.  I'd argue that this is a real problem.  The
semantics of the 500 response are "the server encountered an unexpected
condition which prevented it from fulfilling the request".  This is
overloaded in SOAP to mean a SOAP fault also.  It is this that seems to be
part of the instigation of the SOAPAction header and the 427 response code.
I'd say that an equal resolution is to support a new 5xx series error code
indicating a SOAP fault, remove the SOAPAction header, and have the 500
error code indicate what 427 is used for now.  Or even better, just use 403
or 404 to indicate that the recipient could not process the SOAP message.
Either would be reasonable close to the semantics in RFC1945 and would
express the nature of a SOAP fault. 

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 13:01:24 UTC