Re: Advanced Status Reporting and XML vs HTML

> First question: Is such a format required? 
> My response: Absolutely. HTTP error codes are completely inefficient for
> real application development. They return little to no information, and
> are overloaded to different meanings for different verbs, and in many
> cases help neither application developers who are trying to develop to
> WebDAV (i.e. helping them find mistakes in their code -- e.g. any parse
> error in a PROPFIND is a 400 Bad Request, no help finding the error),
> nor to clients trying to provide meaningful information to their users.
> Adding a code (which can only be done for 80-90 times each for client
> and server) is dangerous because there is no namespace control.

HTTP error codes (and, more importantly, the abstract interface defined
by HTTP) are designed to limit the dependence between client and server
implementations.  Almost all proposals for new codes have been rejected
because they abuse that interface for no good reason, usually because some
client developer was too lazy to read the spec and invented a new code
that had the same *interoperability semantics* as an existing code.

Why, for example, should a parse error in a PROPFIND request result
in a machine-processable interoperability error?  What is the client
supposed to do in this situation?  Dynamically correct its syntax and
resubmit the request on the fly?  If it can do that, then why the hell
didn't it send a correctly formatted message in the first place?
The correct interoperable response code in this situation is 400,
with a detailed response body that highlights the syntax error such
that the application developer can find it.  [The reason why this isn't
done by servers like Apache is because it is far harder to produce
such a page than it is to tell the application developer to RTFM.]

I know of only one status code that should have been added, but was not
because of poor client implementations, and that is the one that should
tell the client to clear any saved authentication information (logout).
I'm sure there are a few others that I have forgotten, but nowhere near
the 80 available in each class of codes.

> Second question: What format should this mechanism take?
> My response: I think that format should be XML (even if doing so didn't
> make the format buzzword-compatible). I don't think I need to elaborate
> on the advantages of using XML, except that WebDAV has pretty much
> already committed itself to the XML bandwagon, and as I've said before,
> it's trivial to parse -- any halfway decent OS or browser should include
> an XML parser as part of the standard package (yes, I'm being facetious
> :).

XML is trivial to parse incorrectly.  I have no problem with adding more
XML to XML responses, or even for creating a specially-formatted XHTML
version of error responses that old browsers could read just fine.

> Third question: When does this data get returned to the client?
> My response: This one is open for debate. I highly disagree with the
> notion that an URL to a static resource is adequate where the client can
> obtain the information is a good idea. Some of the data, as John
> suggests, is dynamic -- the "disk full" example is a good one, as is the
> "file %s is locked by %s" example. I've also expressed my dislike for
> the "embed-XML-in-HTML" solution as making the response prohibitively
> difficult to parse in some client scenarios (client-side browser script
> being the one I'm thinking of), as well as being somewhat contrary to
> the way custom errors are implemented today by web servers (as static
> pages served out to the client). The client should be able to ask for
> the response in the format that it wants it, and get it. For that
> matter, I have often wished for a standard way for a client to indicate
> to a server that it *doesn't* want those bulky custom error pages --
> when my DAV client gets a 400 error, it really doesn't care about that
> 3K of HTML text that comes along with it.

I can think of hundreds of reasons to display that response to the user
and none to hide it.  I know MSIE replaces many error messages with
an idiotic message that some fool somewhere thinks is more user-friendly,
but I refuse to accept that as a paragon of good application design.

BTW, I also don't have any issue with adding this cruft to SOAP.

....Roy

Received on Thursday, 28 December 2000 03:37:17 UTC