Re: Proposal for an HTTP ERR method

Alex Rousskov wrote:
> When/if machines are intelligent-enough to fix themselves, we
> would not need other machines to inform them of bugs; these related
> functions would be integrated).

I agree :)

I think it's about getting the information to where it's most effective.

A server will never be as thoroughly tested by its own admins, nor by
future intelligent software, as it will be by the huge cloud of
diverse clients, each testing for things which the server people (and
those making test suites) haven't thought of.

When you're making mistakes at work, you try to fix them yourself.
But it is still helpful if, when other people notice, they tell you!

> You said "avoids the vicious circle that other workarounds require". I
> fail to understand how ERR proposal is conceptually different from any
> other "bug-reporting interface" proposal as far as that "vicious
> circle" is concerned. The fact that something can be logged does not
> explain the difference to me. Something is logged/recorded with any
> other "bug-reporting interface" proposal.

I think the point is to make ERR automatic.
Any other automatic error reporting->logging system would do just as well.

"<p>Please send bug reports to <a
href='mailto:bugs@foobarwibble.com'>bugs@foobarwibble.com</p>" at the
end of each web page or XML transaction is *not* the same thing.

However, a standard header which points to a URI for posting client
observations -- where the standard is clearly for short, automatically
generated messages of a certain kind -- would do.

But then you have the problem of people spamming the error reporting
mechanism :(

> protocol, you are proposing a
> 
> 	To who it may concern:
> 		The response I have received some time
> 		ago is broken for the following reasons:...
> 		If you think you are somehow related
> 		to that response, please consider doing
> 		something about it.
> 
> protocol. Is my interpretation accurate?

I think so :)

However at least the letter is addressed to the house of whoever send
the broken response.  And it should include the URI and method.

It it's a shared house, they might still find it useful.  If they have
a complicated house, and they're getting letters like this which they
can't decipher, they could consider using better URI distinction.

But, frankly, if they _want_ to receive these messages, they could
advertise that in responses with a "Auto-Feedback" header (see below).

> Other HTTP methods do not followup/depend-on previous transactions
> (and things break when they implicitly do).  Or are you talking
> about other bug-reporting methods? If it is the latter, than what
> you seem to be saying is that your method is at least as bad as
> others as far as bug origin identification is concerned. I would
> agree with that!

I agree!

Reporting bugs by a different path is better in fact.  The client can
potentially report all the headers of the transaction, efficiently
(i.e. it doesn't have to be after each transaction - multiple errors
could be aggregated), as well as text about the problem and a URI
pointing to more detail for the server's human admins.

If servers who are interested in such observations by clients, say as
much using a header "Auto-Feedback: /auto-bugs.pl", then the servers
can totally control where feedback is sent according to who is the
source of the response.

In that way, the feedback can be properly addressed.

Reporting them immediately is just a convenient way of getting it
done, out of the way, and into the same log file.  But if server
admins _want_ that, they can splice messages received by a different
path directly into the logs.  I doubt if they'd want to, but they could.


> I am afraid there is no good technical solution here. It is a cultural
> problem: It is pointless to design a protocol to inform a machine that
> something is broken if broken things "work OK" without being fixed.
> And, vice versa, on a planet where broken things do not work, such a
> protocol would probably not be needed as implementations would test
> themselves to avoid being broken.

I disagree with your depth of cynicism.  Logging errors does sometimes
lead to them being fixed.  It doesn't guarantee it, but makes it more
likely.

Also, no matter how intelligent an implementation, it's self testing
will never be as thorough as the testing done by all the clients using
it.  It's a simple question of resources and diversity -- and the fact
that the specifications are very complicated, inexact, ever-changing,
and usually a bit broken themselves.

-- Jamie

Received on Wednesday, 23 June 2004 14:08:26 UTC