...I know I don't understand all the issues here, but I think I spot one flaw in the argument. This seems to imply that all security holes are the work of the content providers and none related to the servers. In other words, that all servers and their administrators are entirely trustworthy. This is certainly not necessarily true. And if a content provider can compromise security by confusing encodings, so can a server.
As far as the browser is concerned, meta tags in the document _/must not/_ override the headers, as this could result in security holes exploitable by attackers.
The issue is slightly more complicated. The browser /must/ believe the HTTP headers. However, if the meta tags and HTTP headers are in conflict then I believe _the server is at fault_, in not making the correct declaration. In other words, if the document author says (in a meta tag) "this is in UTF-8", then the server should (in my opinion) send the document to the browser with an encoding type of UTF-8. In other words, the server should (again, in my opinion), ensure that the HTTP header is not in conflict with a meta tag, by changing the HTTP header to match the meta tag. However, if a server does not do this, still, then the browser must believe the HTTP header.
Jill
This could become a significant security hole when we get Unicode domain names. A malicious server administrator could register the mojibake equivalent of a legitimate security sensitive domain name and then deliberately serve the mojibake version to users, etc etc.
-- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
