Re: Proposal for an HTTP ERR method

On Wed, 23 Jun 2004, Henry Story wrote:

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

You said "intelligent enough to fix themselves". Now you are giving
examples of something fixing something else. These examples are out of
scope (i.e., they are irrelevant to the discussion).

Here is an in-scope example that illustrates my point: If I am smart
enough to wash my hands, I am smart enough to check whether they are
dirty (and an intelligent-enough machine would be even better at
that!). 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).

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

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.

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

OK. It seems to me that now, instead of proposing a

	Dear Server,
		The response you sent some time ago was
		broken for the following reasons: ...
		Please fix it.

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?

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

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!

> And whoever is sending you the bad xml should be notified.

The above argument is not about necessity/usefulness of
notifications. It is about locating the sender. If you cannot locate
the sender, it may be pointless to send notifications, unless you want
to broadcast them (which seems to be a different design from what you
originally documented).

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

I was saying two things in the original two paragraphs above:
	- second request route may be different from the
	  first request route
	- the response may be created by many agents, some
	  of which may even be invisible to (unreachable from)
	  the recipient

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

Alex.

Received on Wednesday, 23 June 2004 13:08:51 UTC