RE: Advanced Status Reporting and XML vs HTML

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:fielding@ebuilt.com]
> Sent: Wednesday, December 20, 2000 6:18 PM
> To: John Stracke
> Cc: w3c-dist-auth@w3.org
> 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

Received on Thursday, 21 December 2000 04:06:16 UTC