Re: Proposal for an HTTP ERR method

On Wed, 23 Jun 2004, Henry Story wrote:

> If you allow us to imagine a future where resources are intelligent
> enough to fix themselves, we can see how this can help the web heal
> itself, automatically.

If something is smart enough to fix itself, it is most likely smart
enough to test itself, instead of relying on a client to do the
testing. It is also probably smart enough not to trust test results
from untrusted clients.

> 3. This proposal avoids the vicious circle that other workarounds
> require: namely a file somewhere that specifies where to send error
> reports, this file itself perhaps being malformed.

I do not see a conceptual difference in the above context: Both "a
file somewhere" and "a some HTTP method" are bug-reporting interfaces.
Both can be badly broken by a given implementation. And, on this
planet, both would require some human intervention to fix the problem.

> 4. The resource to which ERR is sent is known to be alive, since it
> just responded to the request. The ERR can furthermore be sent as
> part of the same tcp connection.

AFAIK, there is usually no inter-transaction state in HTTP. The ERR
request is not guaranteed to reach the originator of the broken
response, even if the same Request-URI is used. TCP connections do not
help here because they are hop-by-hop.

It is also not clear how the client can determine the true origin of
the error (not to mention connect to that true origin!).  Responses
are often generated (and, hence, corrupted) by multiple true origins
and/or by HTTP intermediaries or even things like ICAP or OPES
adaptation servers that may not even be HTTP-aware.

I am afraid there is no good technical solution here. It is a cultural
problem :-(.

Alex.

Received on Wednesday, 23 June 2004 11:09:43 UTC