- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Fri, 18 Aug 2006 16:19:18 -0400
- To: "Hugh Winkler" <hughw@wellstorm.com>, "Ian Hickson" <ian@hixie.ch>
- Cc: <noah_mendelsohn@us.ibm.com>, "Anne van Kesteren" <annevk@opera.com>, <www-tag@w3.org>
> From: Hugh Winkler > . . . > > 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. You raise an important practical point, but I would imagine that the same tool vendors who are doing it wrong now would again mindlessly add "authoritative=yes" to their generated headers, regardless of the document's actual content type. Then, to distinguish that misuse from really authoritative usage we'd have to add yet another attribute "really-authoritative=yes". And then the same thing would happen all over again, and we'd have to add "really-really-authoritative=yes", and so on. David Booth, Ph.D. HP Software dbooth@hp.com Phone: +1 617 629 8881
Received on Friday, 18 August 2006 20:20:43 UTC