Re: Summarizing the last 192 discussion

At 03:42 PM 03/04/2002 -0500, you wrote:
>Henrik,
>
>On Tue, Apr 02, 2002 at 09:37:26PM -0800, Henrik Frystyk Nielsen wrote:
> >
> > >Now I'm confused. 8-/  I used to believe this, when I thought that
> > >faultHint was authoritative, but now I wonder how you could say that
> > >when, AFAICT, nowhere in the binding does it distinguish between a
> > >fault received on a 200 response, and one received on a 500 response.
> > >Both end up in the success state, and only the faultHint distinguishes
> > >one from the other.
> >
> > I thought we said that the former is simply broken - it won't happen if
> > the implementation is conformant with the SOAP HTTP binding?
>
>Yes, that would be better than the status quo.
>
>It still doesn't address my issue completely, as I would expect that
>SOAP implementations would be "liberal in what they consume".  So,
>without a spec that says anything to the contrary, they would likely
>treat a fault on 200 as a fault.  And that would yield problems for
>HTTP intermediaries, which my company produces.

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. 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. 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.

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

If I have misunderstood, can you correct me with useful case studies.

thanks

BTW, +1 for the fault as a body replacement but the details are difficult...

Grahame

Received on Wednesday, 3 April 2002 17:55:52 UTC