- From: Hugh Winkler <hughw@wellstorm.com>
- Date: Wed, 16 Aug 2006 14:09:39 -0500
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: noah_mendelsohn@us.ibm.com, "Anne van Kesteren" <annevk@opera.com>, www-tag@w3.org
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