Re: Approved TAG finding: Authoritative Metadata

On 8/8/06, Ian Hickson <ian@hixie.ch> wrote:

> ....
> I've been pushing for Web browser vendors to fix this for approximately
> eight years, roughly half the lifetime of HTTP so far.
> ....
> ...ANY BROWSER THAT ACTUALLY
> TRIES TO IMPLEMENT THESE THINGS WOULD LOSE ALL MARKET SHARE. You simply
> cannot make a vendor do something that will make them lose marketshare. It
> won't work. Even vendors that have the best of intentions will immediately
> revert to "buggy" behaviour when implementing the "correct" behaviour
> causes thousands of customer support calls asking why their new browser
> broke the Web.
>
>

Many server vendors have not provided adequate support for authors to
generate the correct Content-type headers. They did not understand the
authoritative aspect of content-type by reading RFC 2616 and
predecessors. Put a different way, they placed a different semantic on
Content-type. So there are content-type headers being served up out
there, some adhering to one, authoritative semantic, and others
adherign to a less authoritative, more "hinty" one. Wrongly, we think,
but there you are.


The real problem is a user agent can't know which semantic the server
has used. Same header name, different meanings.

If servers added new information, maybe a new parameter on
Content-type e.g. "Content-type: text/html;
charset=utf-8;authoritative=yes"

Then browsers could distinguish between the two. Whenever a browser
encountered a missing "authoritative" parameter, well, things would be
no worse than now. When it does encounter the "authoritative" content,
the server promises reliable content types.

New revs of apache, etc. would allow careful admins to put e.g. a new
Authoritative directive in a .htaccess or config, signifying that this
admin has trustworthy processes in place to ensure the correct
content-types by e.g. file extensions or whatever technique the server
uses.

I know this would take some impact away from the TAG finding but it
admits the reality that we have two meanings on the header in the
wild, and most importantly it enables all the benefits highlighted in
the finding. You could possibly consider this a transitional header
attribute that would become the default at some future time.

Hugh

Received on Wednesday, 16 August 2006 19:09:51 UTC