Re: When is a Fault a Fault?

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

For sure, and I'd rather not have to enumerate these.  That's why I
think it's easiest to use broad strokes and say that *if* a response
includes a body *and* uses any 4xx or 5xx response code, then it is a
fault ...

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

Ok.  The phrase "SOAP processor can inform the binding" was confusing
me, but there's enough context to interpret it there.  I don't
personally see "the binding" as being a different piece of software.

> > 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 agree that there are different POVs, and that MUST is the right
conformance level here, but that still doesn't say what the
authoritative determinant of a fault is.

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

That's definitely *a* concern, and is why I asked which was the
authoritative souce.  But it's not the concern I was talking about.
I think my response to Jacek included some thoughts about that.

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 14:50:45 UTC