Re: When is a Fault a Fault?

+1, a hint is just that, the envelope contents should be authoritative IMO.

Marc.

Christopher Ferris wrote:

> I don't buy this at all. Any "hint" in the underlying protocol
> is just that, a "hint". Some protocols may not have an available
> "hint" that can be reused (such as HTTP status response codes)
> which suggests to me that the proper way to address this is
> within the envelope itself. Any "hint" provided by the underlying
> protocol is merely an optimization.
> 
> I would suggest that we say that a SOAP Fault is a SOAP
> envelope containing a SOAP:Fault element as the first child
> element information item of the SOAP:Body element information
> item, period. That makes it abundantly clear and unambiguous
> to a SOAP processor that this is indeed a SOAP Fault message.
> 
> If you wanted to support an edge case such as you describe
> whereby a Fault element is carried in the Body of a SOAP
> envelope (e.g. the gimme the last Fault you issued request)
> but is not considered as a SOAP Fault message then
> the appropriate means for doing so would be to either a)
> wrapper the Fault element in another element that conveys some
> harmless intent (like a SOAP RPC req/resp) or b) add a SOAP
> extension header with mU="1" that says in effect "IGNORE the
> Fault element in the Body of this message, it is informational
> and NOT operational".
> 
> I would strongly object to requiring that a binding specification
> be responsible for providing a mechanism for communicating what
> amounts to little more than a "hint" to the SOAP processor. If they
> want to go there, they are free to do so, but we shouldn't be
> imposing any requirement that clearly cannot be readily fulfilled
> by many communication protocols, email being but one of these.
> 
> Cheers,
> 
> Chris
> 
> Mark Baker wrote:
> 
>> Hi Stuart,
>>
>>
>>> Hi Mark,
>>>
>>> I think that there is a small hook for this in the current HTTP 
>>> binding and
>>> it was probably intended to be a larger hook that it currently seems 
>>> to be.
>>> A property named "transport:faultHint" is used (once) at the 
>>> requesting node
>>> with a boolean value is used to signify the receipt of an HTTP 
>>> response with
>>> a 500 status code.
>>>
>>
>> Ah, didn't see that.  If we go with this though, it should also hold
>> that a Fault is a Fault if it's over 4xx or 5xx.
>>
>>
>>> We need to include a description this property in the table at the end of
>>> section 6 [1]. We can also make use of it at the responding node as a 
>>> means
>>> by which the responding SOAP processor can instruct the binding that it
>>> regards the SOAP response as containing a fault.
>>>
>>
>> I'm unclear what you mean by that last sentence, but I reckon that it's
>> not important to this discussion (right?).
>>
>>
>>> An interesting question is then how we mark out a simlar use/mention
>>> distinction in the email binding.
>>>
>>
>> Good point.  I haven't looked at it yet.  I'll try to do that soon.
>>
>>
>>> There are a number of cases that your question brings up:
>>>
>>>  a) marking of faults carried in HTTP requests     (eg. a one-way 
>>> message reporting a fault in some TBD MEP)
>>>
>>>  b) receipt of an HTTP (POST?) response, status code 500, containing 
>>>     a SOAP envelope that does *not* contain a SOAP fault.
>>>
>>>  c) receipt of an HTTP response, status code <> 500, containing     a 
>>> SOAP envelope that *does* contain a SOAP Fault.
>>>
>>
>> Right.
>>
>>
>>> The original intent of "transport:faultHint" was not so much as to enable
>>> the 'use'/'mention' distinction that you cite on your question. I'm 
>>> not sure
>>> that I really want to go there. I think for the 'mention' use-case 
>>> that you
>>> raise I would prefer to see a way to quote faults inside a SOAP message.
>>> That way, the primary way to know whether a fault is a fault is 
>>> merely its
>>> unquoted presence in a SOAP message. Yes... do the right thing with the
>>> status codes underneath aswell... but make the distinction clear in 
>>> the SOAP
>>> message.
>>>
>>
>> Which mechanism are you suggesting be authoritative?  I would be
>> uncomfortable with using anything other than the success/fail mechanism
>> of the underlying protocol, where present.  And where it's not present,
>> I don't think it matters much how it's determined, as long as it's
>> standardized in the binding.
>>
>> Another option is including some information within the envelope to
>> indicate the intent, but that feels uncomfortable to me.  Not sure
>> why exactly, but I'll think more about it.
>>
>> MB
>>
> 
> 


-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Monday, 4 March 2002 12:27:04 UTC