Re: Proposal for an HTTP ERR method

On Wed, 23 Jun 2004, Henry Story wrote:

> Since every consumer of XML is faced with the ietf and w3c standards
> that state that one should *not* consume badly formed responses,
> everyone is going to need to be able to report errors if we don't
> want market pressures to lead us down the path of incompatible and
> broken implementations as html did.

Can you explain the logic here? How can a "protocol to auto-report
errors" reduce market pressures on XML consumers to be tolerant to
malformed XML?

> The problem with having to find a specific error service uri, is
> that this requires one or more extra requests to other uri, many of
> which may themselves be broken.

Are you trying to optimize the number of messages on the wire?  Or are
you saying that an "error service at error service uri" is more likely
to be broken than the implementation that handles ERR request? These
are very different optimization goals!

> The advantage of ERR is that I don't need to know about any other
> URI to be able to notify it of the problem. I have already
> communicated with it, so I just need to notify it of the ERR.

The problem is that HTTP does not have a useful notion of "already
communicated with it". "It" can be rather complex and may partially or
fully change from one request to another.

Another ERR disadvantage is that it requires content-serving agents to
handle error reports instead of assigning error-report handling to
error-handling-agents. Things that serve content may not be the best
things for fixing that content (for numerous reasons).

> There is currently a fundamental asymmetry in error reporting
> between the client and the server.

Depends on your point of view, I guess. Clients report errors to
client "owners/users". Servers report errors to server "owners". This
part is very symmetric. While it is true that servers also report some
errors to clients, that is a simply a side-effect of the fundamental
request/response transaction interface: the server has to respond. The
error response that the server sends is not intended to auto-fix the
client.

There is also a fundamental assumption of transaction atomicity,
making one transaction independent from another (except for caching,
which is a low-level performance optimization hack that is supposed to
be transparent to higher-level agents).

> Every request allows the server to report an error, but none allow
> the client to report an error back to the server. This is one reason
> this seemed like this proposal might help restore the imbalance.

You may be trying to change a side-effect of fundamental principles
(see above). That may not be possible without changing those
principles first.

Alex.

Received on Wednesday, 23 June 2004 14:09:57 UTC