Subject: RE: Advanced Status Reporting and XML vs HTML

From: "Sean Lyndersay" <[email-masked]>
Date: Thu, 21 Dec 2000 00:26:39 -0800

Advanced Status reporting, as Roy suggests, is really about defining a
mechanism for returning an error (or warning, or informational status)
in some machine-readable (read: easily-parsable), extensible way. It is
(almost) coincidence that the format would find use in HTTP and/or
WebDAV. 

I see (at least) three questions arising from this, which I'll list
below, along with my off-the-cuff responses.

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.

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

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.

Sean

> -----Original Message-----
> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2000 6:18 PM
> To: John Stracke
> Cc: [email-masked]
> Subject: Re: Advanced Status Reporting and XML vs HTML
> 
> On Wed, Dec 20, 2000 at 08:58:52AM -0500, John Stracke wrote:
> > "Roy T. Fielding" wrote:
> >
> > > Accept headers are a bad idea.  They have always been a bad idea.
> > > A better solution is to provide the client with the primary
content
> > > choice and a means of obtaining the new content.
> >
> > But, in this case, the content is an error message; this approach
would
> > require
> > that the error message be stored on the server for a time, available
at
> (say)
> > some other URL.  That's kind of an unpleasant
requirement--especially if
> the
> > error that's being reported is "disk full".
> 
> That is why my message had more text than what you quoted above.
> 
> I currently do not believe that any error extension mechanism is
> necessary, but even if it were to be necessary there are many ways
> to include it that would only cost the application a couple bytes
> on the response that would be ignored by anything not prepared
> to handle it.  Therefore, generating a new standard for XML content
> that describes an extension mechanism for status codes is not only
> the equivalent of using a bazooka for domestic rodent control, it
> also needlessly ties HTTP to XML responses.
> 
> ....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 28 Dec 2000 00:41:47 -0800

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

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

> 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