Re: When is a Fault a Fault?

>  Mark,
>  I apologize for using the term REST before in this 
> thread because I mistakenly connected REST and non-tunelling, 
> where the REST issue is orthogonal.

No apology necessary.  Both "tunnel" and "REST" seem to appear together
in many discussions, so it's no surprise to see them again here.

>  The difference in your HTTP 404 and a SOAP Fault, as I perceive
> it, is the fact that there is no prescribed content for HTTP
> errors whereas there is a specific structure of the content for
> SOAP Faults which can be checked for.

That's true, but perhaps not the problem you appear to be suggesting
(if I understand your reasoning for bringing this up).  HTTP already
includes a means for signifying whether "content" should be
considered content, or a failure.  It is a Good Thing that it
doesn't require any format of failures, since that allows us to
say, in Apache .conf-speak;

  ErrorDocument /404.html

> Moreover, we expect that
> there will be bindings to one-way protocols and request/response
> patterns built on top of these bindings. In such cases (say email
> binding) it is inappropriate to signal that the transmitted
> message is in fact a fault message since the information is
> already in the message itself.

I disagree.  We are talking about two pieces of information here, not
one.  There's the information about the type of the content (a SOAP
fault), and then there's the information about whether it should be
processed as a fault or not.

>  I still disagree that SOAP faults should be returned with HTTP 
> 500 status code, but I acknowledge that the WG has made the 
> decision to support this and I don't think it is a big issue. 
> (I am one of these tunelists. 8-) )

Yep.  Well, I'm not a tunnelist, and I think this is (I was going
to say "was", but it's clear that it isn't over yet 8-) the biggest
architectural issue faced by this WG.

>  What can we expect from transport bindings? They must be able to
> actually (try to) transfer the infoset and that's it.

They must try to transfer the infoset with the transfer semantics
from the underlying protocol.  That means respecting the method
semantics, and also the failure semantics.

> If we want
> always to transfer some additional data, I say stick it in the
> infoset which is always transferred. Otherwise we cannot create a
> TCP binding whose operation is to open a TCP connection, feed in
> the XML serialization of the infoset, and close the connection.

I agree that for transport bindings (to transport protocols like
TCP, not to application protocols like HTTP), that a mechanism needs
to be provided to indicate whether the fault should be processed as
a fault.  I just disagree that this mechanism should be the
authoritative determinant of when a fault is a fault for an application
protocol binding.

> We'd have to create a format for the "outer" data, for example
> sending a MIME content with one necessary header - the faultHint.
>  Using the non-tunelling view in this case leads us to a 
> potential inconsistency (200 OK and a fault message), which IMHO 
> is a reason _for_ the tunelling use of HTTP or disallowing other 
> protocols, if we want to be consistent.

But that's not an inconsistency.  Like I said in my example, what if I
wanted a debugging interface on my components such that I could ask
"give me the last fault you sent".  In the tunnelled view of SOAP,
there's no way to know whether what you're getting is the fault
you're asking for, or a fault generated because of your question.

> I'd hate it if we say "if 
> the protocol binding says the message is/isn't a fault message, 
> this is the true information, otherwise look at the first member 
> of the Body."

Yes, I'd hate that too.  That's why we need a single authoritative
piece of info that processors can use, and why I'm suggesting that for
transport protocol bindings, we can have something in-band, but that
this mechanism SHOULD NOT (would like to use MUST, but I don't think
it's strictly required) be used for application protocol bindings.

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 17:01:27 UTC