Re: Proposal for an HTTP ERR method

Henry Story wrote:
> 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. 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.

Eh?

What's the difference between:

   1. Having to POST /report-errors.pl HTTP/1.1 etc. etc. with report.

   2. Having to ERR /index.xml HTTP/1.1 etc. etc. with report.

?

The only difference I can see is that the former is more useful to the
server people, because they can cause reports to go to the responsible
person(s) for the exact response which has an error.

Example:
========

The exact server which is relevant to a particular response may depend
on factors which only the server people know.

This is why a server _must_ be what is responsible for providing that
error reporting mechanism.  Hence a bug-reporting URI header.

You may have 100 back-end servers all behind a load balancer, but only
1 of them is sending "Content-Type: text/xml" due to misconfiguration.
All the others are sending "Content-Type: text/xml; charset=utf-8".

This is a crucial point.  If you don't see this, you won't see why
sending an ERR immediately after the buggy reponse isn't helpful:

   *Every single request to the world-visible load balancer is proxied
   to a different back-end server at random*.

In that case, it's useless to send an ERR immediately after getting
"Content-Type: text/xml", because the ERR will be forwarded to the
_wrong_ server 99 times out of 100.

Whereas, if the back-end servers are able to specific a bug URI, then
errors can be forwarded to the _correct_ server always.

How?  Each back-end server provides an appropriate header, like this:

   Bug-URI: /bug-logger.pl?server=box54

Then the server people see the report, and they are all referring to
box54, and they know what to fix straight away.  (Paranoid servers who
don't want to reveal their topology use an opaque cookie instead)

As a client, you cannot possible know the topology, or know who is
responsible for each response you receive.  The server administrators,
however, can configure their systems like that _if_ they want to
collect that data.

That is infinitely more useful, to the server people, than an ERR
response which has no association whatsoever with any part of the
server farm.

> There is currently a fundamental asymmetry in error reporting between 
> the client and the server. 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 right about the principle of reporting.  But your method of
sending ERR is flawed, primarily because it's totally unrelated to the
request it's reporting on.

Remember, even if a client think's it is using a single TCP
connection, by the time it reaches the servers that is no longer true.

Every request is split up independently, and retains no association.

So the servers have no idea which response your report applies to.

-- Jamie

Received on Wednesday, 23 June 2004 14:31:55 UTC