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

Re: When is a Fault a Fault?

From: Mark Baker <distobj@acm.org>
Date: Mon, 4 Mar 2002 14:06:29 -0500 (EST)
Message-Id: <200203041906.OAA15425@markbaker.ca>
To: jacek@systinet.com (Jacek Kopecky)
Cc: chris.ferris@sun.com (Christopher Ferris), skw@hplb.hpl.hp.com (Williams Stuart), xml-dist-app@w3.org
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
-- 
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:15:48 GMT

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