RE: When is a Fault a Fault?

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.

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.

An interesting question is then how we mark out a simlar use/mention
distinction in the email binding.

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.

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.

Thanks,

Stuart
[1]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2-f2fsnap.html#soaptmep

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 03 March 2002 06:17
> To: xml-dist-app@w3.org
> Subject: When is a Fault a Fault?
> 
> 
> I went over the binding framework and the HTTP binding and noticed a
> problem; no where is it stated how SOAP processors should recognize
> faults.
> 
> The issue is that sometimes a SOAP node may want to send a message
> that includes a Fault, but is not intended to be processed as a
> Fault.  An example would be if a SOAP node is asked, perhaps via a
> debugging interface, to return the last fault it sent.
> 
> Using HTTP as an example, the HTTP response code is used as the
> authoritative determinant of the intent; if it's a 2xx response, then
> the Fault is not processed as a Fault.  If it's a 4xx or 5xx, then it
> is.
> 
> What I suggest we do is;
> 
> 1) update the binding framework to state that each binding should
> declare that the authoritative determinant of whether a message is a
> fault or not should be the underlying protocol
> 
> 2) update the default HTTP binding to state that a SOAP Fault MUST
> only be processed as a SOAP Fault if the response code is 4xx or 5xx.
> 
> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
>

Received on Monday, 4 March 2002 05:33:41 UTC