Re: Summarizing the last 192 discussion

Chris Ferris writes:

>> Mark,
>> 
>> I'm not interested in allowing a SOAP Fault to be returned
>> on an HTTP 200 OK response. If it is, then it would have
>> to be considered a bug and would constitute a
>> non-interoperable implementation, IMO.

I agree. Specifically, most likely a bug at the other end of the
connection.  I hope the binding spec is clear that fault's SHOULD 
only be sent in responses marked 500 (or maybe 5XX).

>> I'm not sure that I agree with Noah that the binding should
>> be concerning itself with attempting to right the wrong of
>> another node by comparing the message contents with the response
>> code. I suppose that it might be free to do so (be liberal in
>> what you accept and conservative in what you send principle)
>> but the performance penalty would be a little severe.

Actually, I never strongly advocated making the 
check or "righting the wrong" in the receiving binding.
I have no strong feeling on this.  I certainly am not requesting
the change Mark ascribes to me (I.e. to change the transition
table to specifically allow fault hint to be set on a 200.) 
I would not mind indicating that a binding MAY 
decline to accept (I.e. transition to a fail state) that
contains a fault in a 200.  As you say, I would not require this
and...

>> My bottom line is a SOAP Fault is a SOAP Fault regardless of
>> the binding. The faulthint property is just that, a hint.

...as you say, if this buggy message is received, and your
binding implementation chooses not to reject it outright,
then I agree that it MUST be treated as a fault per the
SOAP processing rules.

>> Cheers,
>> 
>> Chris

Thanks. 

Noah

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Thursday, 28 March 2002 12:38:02 UTC