Subject: RE: ERR header (NEW ISSUE: Drop Content-Location)

From: "Joris Dobbelsteen" <[email-masked]>
Date: Sun, 3 Dec 2006 21:51:19 +0100

Awareness...
I believe we are talking about a technical solution for a problem causes
by people not being aware of the havoc caused (or are just plain
ignorant, which is best not to assume).

Now my doubts are that such technical solutions will resort desired
effect.

The implementors screw up, the administrators get the effects. I'm
considering whether this would get a true result and would people start
acting, rather than getting so annoyed to build filters protecting
against it.
How about feature abuse? Those captcha things are getting more and more
common every day. Google and Microsoft protect by using a captcha before
site entering, Yahoo requires you to have an account.

My believe is that validation tools (single reference) would resort
better results, provided that they are used by the development/test/QA
teams. In such situations the people that develop the product are
actually caring about compliance, instead of just advertising it as
such.

This leaves to my last thoughts, how well are browsers able to
(automatically) detect incorrect behaviour? If a validation tool can do
it, so can they. It they can't do it, is a validation tool capable to do
so?
My reasoning, if they were capable, they would have build mechanisms to
protect themselves against broken systems and make the functionality
available to others.
In fact, is it even possible to detect this problem using automated
systems or would it require a human to find out?

In such case, browsers would rather be equiped with such features that
can be turned on for developers/testers of web applications. Maybe that
would be a good middle way.

- Joris

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Julian Reschke
>Sent: zondag 3 december 2006 11:00
>To: Henrik Nordstrom
>Cc: Henry Story; [email-masked]
>Subject: Re: ERR header (NEW ISSUE: Drop Content-Location)
>
>
>Henrik Nordstrom schrieb:
>> ...
>> I think I have now completely lost the picture on when/why adding an 
>> ERR method may be useful to the level that it outweights the 
>negative 
>> aspects or cost of deployment.
>> ...
>
>The interesting part (to me) is that essentially the 
>deployment cost for a simple version of ERR is zero: servers 
>that don't know it are likely to log it; which may be 
>completely sufficient if the server admin occasionally looks 
>at the log files.
>
>Best regards, Julian
>
>

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 05 Dec 2006 07:57:37 +0100

> ignorant, which is best not to assume).

Same here.

> acting, rather than getting so annoyed to build filters protecting

Quite likely to happen. Well, actually already happens with filters
being deployed infront of webservers restricting which methods is
allowed to reach the web server.

> actually caring about compliance, instead of just advertising it as

agreed.

> it, so can they. It they can't do it, is a validation tool capable to do

Depends on the error.

404's and similar they can very easily detect, but so does the server
error logs without any additional reporting.

Significant HTML coding errors is easy, and sometimes worth reporting.

Bad document base (which started this discussion) is not so easy if it
goes outside the site. Well, sometimes it's easy i.e. when getting a
authorative "host not found" on the hostname of the base URI. In worst
case a timeout is needed. If it's inside the same site then the existing
error reporting is already sufficient.

> systems or would it require a human to find out?

It's possible for many errors. But I still do not think it's worth the
errort and the problems involved in getting the scheme to work.

Quite likely automatic reporting from the browsers is not desireable,
while these are the ones most likely to find problems. This to avoid the
system backfiring on itself when it's the browsers which are broken or
abuse.

This also goes hand in hand with the fact that in most cases the ones
receiving the reports will need quite a bit of additional guidance on
why it's an error and why they should care about it.

And the webmaster@ is already an standards track method of contacting
the human responsible for a web site. Completely ignored by very many,
but still standards track.

In systematic errors the most important step is to properly identify the
source of the error, not the error as such. The ones responsible for the
web sites often does not know the low details, or care very much as long
as it works in the one or two major browsers. Quite often it's a vendor
involved, and by making the vendor aware of the problem it is possible
to get it fixed proper on a longer time scale, either by having the
vendor product fixed, or by having them explaining the problem in
suitable documentation raising awareness of why it is a problem and why
it should be avoided.

Regards
Henrik