W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

RE: When is a Fault a Fault?

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Mon, 4 Mar 2002 17:44:38 -0000
Message-ID: <5E13A1874524D411A876006008CD059F1929D3@0-mail-1.hpl.hp.com>
To: "'Mark Baker'" <distobj@acm.org>
Cc: xml-dist-app@w3.org
Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 04 March 2002 15:28
> To: skw@hplb.hpl.hp.com
> Cc: xml-dist-app@w3.org
> Subject: Re: When is a Fault a Fault?
> 
> 
> 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.

Not sure how may of the conditions that give rise to:

   10.4.1    400 Bad Request .........................................65
   10.4.2    401 Unauthorized ........................................66
   10.4.3    402 Payment Required ....................................66
   10.4.4    403 Forbidden ...........................................66
   10.4.5    404 Not Found ...........................................66
   10.4.6    405 Method Not Allowed ..................................66
   10.4.7    406 Not Acceptable ......................................67
   10.4.8    407 Proxy Authentication Required .......................67
   10.4.9    408 Request Timeout .....................................67
   10.4.10   409 Conflict ............................................67
   10.4.11   410 Gone ................................................68
   10.4.12   411 Length Required .....................................68
   10.4.13   412 Precondition Failed .................................68
   10.4.14   413 Request Entity Too Large ............................69
   10.4.15   414 Request-URI Too Long ................................69
   10.4.16   415 Unsupported Media Type ..............................69
   10.4.17   416 Requested Range Not Satisfiable .....................69
   10.4.18   417 Expectation Failed ..................................70

result in a request message being delivered to the SOAP node at the HTTP
origin server or which are (could be/should be) handled directly by HTTP,
and effectively return an 'empty' response (hence no fault bearing SOAP
envelope).

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

The only place that "faultHint" is currently spoken about is with respect to
the receipt of an HTTP POST response message by the requesting SOAP node.
The last sentence is about mirroring something similar so that the SOAP
processor can inform the binding that it regards the outbound message as
being a fault message and that the binding should mark it appropriately (ie
status code 500).

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

From the POV of processing the SOAP message I'd like to regard the SOAP
message as authoritative. From the POV of HTTP infrastructure, proxies,
caches, routers..., certainly those that can't usefully peek inside the SOAP
message then really all they have to go on is the status code.

This is probably one of those places where we should properly us a MUST in
the HTTP binding spec, to say that the generator of a SOAP message MUST
ensure the appropriate status code is used (and go on to say what the
appropriate status code is). The defendable interop concern is the sustained
correct operation of existing infrastructure... and if you don't do as the
MUST say's then you are non-compliant with the binding spec.

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

Basically, I think your concern is due to there being two (or more)
mechanisms to signify the same information and in those cases where there is
inconsistency, do you resolve in favour of what the message says of itself
or status information from the underlying protocol. I think we should
probably have MUSTs that require consistency, such that the generation of
something inconsistent is regarded as non-conforming. 

> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com

Regards

Stuart
Received on Monday, 4 March 2002 12:44:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT