Re: Proposal for an HTTP ERR method

[I am also cc ing this to atom-syntax, just so those that are 
interested there to continue this discussion can move it over here. A 
log of it can be found here:
http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/
]

On 23 Jun 2004, at 17:09, Alex Rousskov wrote:

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

I am smart enough to test my code. I still find errors in it. Recently 
my nice OSX machine crashed. Apple tests its code as far as I know.
:-)

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

Fixing the problem will most probably require some human intervention.
But if you have just downloaded some broken XML and still have an open 
connection to the server, why not just send an ERR at that moment to 
the server. Then it can be clearly logged, and it is also clear what 
the problem is about.

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

Well who-ever along the road gets the request will want to deal with 
it. If a cache receives the request for example it might decide to 
clear the document from its cache and re-fetch the page in case the 
problem has been fixed.

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

The same problem exist for all of http. You cannot determine who
sent the response to you. So this is no more problematic than the other
methods. And whoever is sending you the bad xml should be notified.

If you are saying that your first request may have gone down one route, 
which returned you the bad xml, whereas your ERR went down another 
route which would have returned you good xml, then that is an 
interesting point.

How could one deal with that situation, if that situation indeed exists?


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

Received on Wednesday, 23 June 2004 12:25:47 UTC