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.
 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. 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 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-) )
 What can we expect from transport bindings? They must be able to
actually (try to) transfer the infoset and that's it. 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.
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. 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."
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/




On Mon, 4 Mar 2002, Mark Baker wrote:

 > This is not a REST specific problem, it's specific to all non-tunnelled
 > uses of an underlying protocol that distinguishes between "data" and
 > "error" on responses (i.e. application protocols).
 > 
 > For a real-life example of this, consider the difference between these
 > two URIs.
 > 
 > http://www.ibiblio.org/not-a-real-resource
 > http://www.ibiblio.org/404
 > 
 > The former is not a real URI, and so it is returned with a 404 status
 > code.  The latter identifies what is returned when a resource is not
 > found, but invoking GET on it returns the *same content* as a 404, but
 > with a 200 response code, ensuring that the browser can bookmark it,
 > cache it, etc..
 > 
 > Requiring that the content be different to indicate this difference in
 > semantics seems like unnecessary bloat, especially when I thought we had
 > already decided that reusing the fault semantics from the underlying
 > protocol was a Good Thing (per our decision to not send faults over HTTP
 > 200).  While transport (not application) protocol bindings may need
 > this, it isn't clear that there needs to be a standardized means of
 > communicating it within the envelope for these protocols, especially
 > when it will only complicate application protocol bindings.
 > 
 > MB
 >

Received on Monday, 4 March 2002 14:21:17 UTC