Re: Summarizing the last 192 discussion

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

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

Cheers,

Chris


Mark Baker wrote:

> I don't think I have any more to add to this discussion at this point.
> It's the same old issue that we've never come to an agreement on.
> 
> So, what I can extract from this discussion is this;
> 
> - everybody likes the resolution to issue 12
> 
> - I like the current state tables in our HTTP binding, specifically
> 7.4.1.2/7.4.1.3 (of the latest editor's draft), as it reflects my view
> that a fault can only be processed as a fault when received with a 4xx
> or 5xx response code, i.e. FaultHint is never set on a 2xx (hmm, it's
> still only set on 500, not 4xx).
> 
> - Noah and Chris appear to want to change 7.4.1.2 to say that if a
> fault is received on a 2xx, then FaultHint would be set to true.
> 
> Does that capture the current state of things?
> 
> MB
>

Received on Wednesday, 27 March 2002 22:28:14 UTC