HTTP vs. SOAP intermediaries

On Thu, Apr 04, 2002 at 08:46:57AM +1000, Grahame Grieve wrote:
> can you explain the problems a bit better? The trouble I have is that I'm
> a client application. Someone sent me a message. the binding claimed it was
> ok (200 OK), but when I actually looked in it, I found that it contained
> a SOAP fault, and not what I was supposed to find. At this point, I have
> 3 choices:
> 
> 1/ handle the fault in the SOAP packet as if it was a proper fault
> 2/ handle a different fault, which is that the binding didn't match the
>     fault
> 3/ pretend that it was a coherent message, and go on processing
> 
> Now it's obvious (to me) that #3 is not an available option.

I'm glad you believe that, but I don't believe I've seen or heard of a
SOAP 1.1 implementation that treated a fault received on 200 response as
anything other than a fault.  I don't see how anything would change with
SOAP 1.2 unless we say something to the contrary.

> So I am left
> with a choice between 1 & 2. Which both have the same outcome - a non
> completion of the operation.
> 
> Now in your example from before, you were interested in the completion
> of the operation. (I thought). So it seems to me that the primary interest
> here is that a fault be wrapped appropriately.

Not wrapped, but reflected in the underlying protocol.

> And insisting the a "fault
> with a 200 status is not a fault" is partially trying to use a stick to
> force responders to comply with a regime that makes life easier for HTTP
> intermediaries doing who knows what, and partially self deceptive.

Hmm, I'm not sure how to respond, because we clearly see the protocol
stack quite differently.

From Roy Fielding's dissertation;

"What makes HTTP significantly different from RPC is that the requests
are directed to resources using a generic interface with standard
semantics that can be interpreted by intermediaries almost as well as by
the machines that originate services."
  -- http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2

In the chameleon use of SOAP with HTTP, the generic interface is
maintained (GET, PUT, POST, DELETE, plus the headers and response codes)
so that SOAP/HTTP intermediaries can understand what's going on almost
as well as HTTP intermediaries.  Obviously SOAP intermediaries could
look at SOAP headers, where HTTP intermediaries could not, but HTTP
intermediaries can still look at the method, the HTTP headers, and the
response code.  So it can know what the client was trying to do, the
metadata about the payload, and whether or not what was attempted
succeeded or not.

> As an application designer, to refuse a request, I have a choice of
> answering with a boolean false, or a fault. Or a number of other ways.
> How can an intermediary understand what is going on here? It has a
> total lack of knowledge of the interaction model running across it,
> unless it partakes in that interaction model, and then the status becomes
> irrelevent

An HTTP intermediary doesn't have a total *lack* of knowledge, it can
have a near total *understanding* of what is going on.  See Roy's blurb
above.  I couldn't explain it any better than that.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Thursday, 4 April 2002 10:04:56 UTC