Subject: Re: Advanced Status Reporting and XML vs HTML

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 19 Dec 2000 15:44:04 -0800

> So, my proposal is to kill two birds with one stone.  We pretty much agreed
> that the client should advertise its support for this feature in requests,
> presumably by adding a header.  It's straight-forward to allow this header
> to provide information on what kind of thing the client wants to receive.

I don't think so.  Every time the client advertises support for a feature
it adds to the request latency of every request and creates a new variable
against which content selection algorithms must apply.

This goes back to the discussion of content negotiation in HTTP/1.0.
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. Or, if the alternatives
are small, as in this case, just include the status in such a way that
it has no adverse impact on clients that do not understand it.

....Roy

---

From: John Stracke <[email-masked]>
Date: Wed, 20 Dec 2000 08:58:52 -0500

"Roy T. Fielding" wrote:

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

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Some days, it just doesn't pay to gnaw through|
[email-masked]|the straps.                                   |
\===============================================================/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 20 Dec 2000 18:17:47 -0800

> 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: John Stracke <[email-masked]>
Date: Thu, 21 Dec 2000 10:12:18 -0500

"Roy T. Fielding" wrote:

> Therefore, generating a new standard for XML content
> the equivalent of using a bazooka for domestic rodent control,

On this you may be right, but...

> it

...this proposal is only for DAV, which already uses XML.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Help stamp out vi in our lifetime!           |
[email-masked]|                                             |
\==============================================================/

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 27 Dec 2000 19:38:16 -0800

Got any suggestions for how to do this?

You may disagree with my assessment of the requirements/goals of this
project, but here's the way I see it:

1) We must not use a header to return advanced status information.  There's
too much of it.  Servers must be able to return, in a single response,
information about multiple resources, much like today's 207 Multistatus.
The simplest example of this is a MOVE of a large directory:  the server can
report every locked child resource, rather than force the client to discover
one by one which ones are blocking the MOVE.

2) We should not return mime/multipart to clients that are used to receiving
a regular HTML body.  IIS and Apache both currently return ordinary HTML
bodies on error messages, and browsers are used to displaying those.  We
don't want to screw those clients up.

3)  Having an extra 25 characters in the client's request is preferable to
having multiple formats returned in the server's response.  This counts also
for embedding XML inside the HTML body:  why add an extra 100-1000
characters in the server response if it can be avoided by having clients
that want advanced status send this extra header?  Some folks have slower
uplinks than downlinks, but I still think that an extra 25 chars in the
client response will be a price they will find worth paying.  Ask the client
developers -- I think they're in favour of this.

4)  Keeping the additional information around on the server for clients to
query later may be unacceptable to server implementors.  It requires the
server to maintain state and do extra disk writes.  It must come up with two
formatted result bodies, rather than just one.  Since the server must handle
many client requests, this does not seem the way to let the server scale.
Are you aware of any server implementors who would find this option
acceptable?  It's unacceptable to me!

Lisa

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy T. Fielding
> Sent: Tuesday, December 19, 2000 3:44 PM
> To: [email-masked]
> Subject: Re: Advanced Status Reporting and XML vs HTML
>
>

---

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

> Got any suggestions for how to do this?

Lot's of them, but most would start with trashing the DAV object
model and starting over.  That is the direct cause of this exponential
error expansion.  But given that this isn't an option right now,
I'd be satisfied with limiting this proposal to DAV responses and
simply including the extended XML tags in every error response
regardless of what the client requested.

> one by one which ones are blocking the MOVE.

I suppose you wouldn't be satisfied by this response: 207 violates HTTP
already by including an error message within a successful response.
How you change 207 responses is of no concern to me.

> don't want to screw those clients up.

I never suggested a multipart.  Too many wasted bytes.

> developers -- I think they're in favour of this.

Client developers are notoriously unaware of the network impact of
such a decision -- look at the values sent in the accept header fields
for confirmation of that.  The reason that 2000 characters (just to be
extreme) added to every error response is better than 25 characters
in every request is because requests far outnumber errors, request
characters are always in the critical path of latency, and the added
latency of error responses is perceived as a bad thing (i.e., at that
point the user wants as much information as they can get).

But I didn't suggest 2000 characters be added.  I suggested that a
single XML tag be used for the additional information if it is expected
to be used for interoperability.  <DAV:EEC val=nnnnnn /> is more than
sufficient given the requirements stated so far.

> acceptable?  It's unacceptable to me!

I never suggested that either -- someone else produced it as a paper tiger.
Such information is already being supplied in the HTML messages, except
where doing so presents a security issue.  There is no reason why the
same information can't be formatted according to some pseudo-standard
like XHTML, with special dav attributes if anything more is needed
(such as easy-to-parse numeric error codes that correspond to whatever
implementation-dependent semantics you care to reveal).

However, I am not the one proposing a change to the protocol.  I think
you need to define and defend why an additional error mechanism is needed
to support application-level interoperability in the first place.  Is it
because the protocol is deficient, the DAV design is deficient (introducing
too much complexity for the sake of saving one round trip), or because
the currently proposed extensions are bogus?  That will determine the
scope of this extension and how it should be implemented far better than
any decision by committee.

HTTP has consumed less than 20% of its error code space in seven years
of use.  That is because the abstract interface of performing actions
on a resource does not have a great deal of variance that needs to be
revealed to an independent client.  HTTP only uses the status code to
tell the client the essential aspect of the status: what it should do
about the situation without further human intervention.  Everything else
that can be used by automated mechanisms is in the response header fields,
and anything that might be used by a human is in the response body.

Neither authoring nor versioning are sufficient problems to generate
such a great need for error codes.  The problem is the way that the
protocol is being extended to perform them.  Performing compound actions
multiplies the complexity of interoperability.  Creating properties
as a pseudo-independent yet dependent adjunct to resources multiplies
the complexity again.  Defining versioning as a property will multiply
it as well.  You are now dealing with a 1xMxPxV universe of interoperability
failures instead of a 1x1 universe.  Extending the status code mechanism
isn't going to fix that.

....Roy

---

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

Ooops...  I meant to say

> latency of error responses is perceived as a bad thing (i.e., at that
                               ^not

....Roy