- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 23 Jun 2008 21:17:39 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5776 --- Comment #6 from Rob Burns <rob@robburns.com> 2008-06-23 21:17:39 --- (In reply to comment #5) > It's an interesting idea, though the experience we have with <script> (which > ignores Content-Type headers) is that the net result of offering this won't be > to help authors override incorrect configurations, it'll be to encourage > authors to not bother with correct configurations in the first place. Yes, that was a concern I have as well. One thing that occurred to me is that UAs could be directed (as in MUST) include a special request header to indicate that this resource was being processed in a different way than its inherent type. That way server admins could monitor the logs for resources where the processas type was frequently different than the server configured type. This would be a red flag to server admins that there was a misconfiguration somewhere. Similarly, the HTML5 draft could direct authors to contact server administrators to update the file configuration rather than resorting to misusing this attribute. To me the goal should be to have accurate metadata from servers about content type and this attribute should only be used to alter the type from its inherent type. However, even the current practice of using content-type headers both for the inherent content type of a resource and for a special case process as content type undermines the goal of accurate server metadata. So the addition of a processas attribute for HTML should be accompanied by the introduction of a real mime-type http header into the http specification. That way the content-type can slowly be phased out and -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 23 June 2008 21:18:18 UTC