This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
* Authors may want to treat a resource as a type for embedding or linking different than the resources intrinsic type * HTTP attempted to provide some solutions especially for tailoring the processing of content to an authors needs, however: - because of the history of server-side and client-side http UAs, the content-type headers no longer serve this purpose - any HTTP solution may not be available to all HTML authors: i.e., those who have no access to configure the server or are not using an HTTP server for delivery - providing an HTML solution permits a single resource with only one representation to be processed in various ways while an HTTP solution requires either duplicating the resource or providing a symbolic or hard linking the same resource to provide different HTTP header metadata which may require additional network traffic as well - new headers could be added to HTTP, but it still would not provide an HTML internal solution Some attribute allowing authors to fine-tune the handling would be ideal. For example an HTML tutorial might include side-by-side iframe elements loading the same resource: one as text/html and one as text/plain. (see http://esw.w3.org/topic/HTML/LinkAndEmbeddingAttributes for evolving solution proposals) [author issue, minor added implementation, attribute only solution]
How is this different from issue 5773?
sorry, I meant to use a different summary. This is for author control over handling of embedded content and the bug # 5773 is for author control over handling of linked content. Sorry for the mix up.
So this is a request for a way to override the type of a resource in an <iframe> from the HTML side?
(In reply to comment #3) > So this is a request for a way to override the type of a resource in an > <iframe> from the HTML side? > yes, but for any embedded resource (iframe, object, video, etc.). Also I think it should be separate from the type attribute which never worked as specced and carries too much baggage with it now. Something like processas or treatas or something like that would make a clearer mnemonic for authors.
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. Still, it could be useful. Let's consider this at some future time when the gap between what browsers implement and what new features HTML5 has waiting for them to implement is lower.
(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
(In reply to comment #3) > So this is a request for a way to override the type of a resource in an > <iframe> from the HTML side? If we do this, we should carefully consider the security implications of overriding the server-provided Content-Type. For example, suppose a web site lets users upload avatar images and serves the bytes of the uploaded images with a Content-Type of image/gif. Now suppose the attacker uploads an HTML document as his or her avatar. If the UA let's the attacker override the server-provided Content-Type, the UA will execute the attacker's script in the sites security context (i.e., the UA will have introduced an XSS vulnerability into the site). So some extent, sites already have to cope with browsers overriding the server-provided Content-Type due to content sniffing. Many sites have spent extensive effort reverse engineering UA content sniffing algorithms. For example, Gmail pads text/plain attachments with 512 space characters to foil IE's text/plain sniffer. Explicitly overriding the Content-Type, say to text/html, would defeat this countermeasure and introduce an XSS vulnerability into Gmail.
(completing comment #6) "That way the content-type can slowly be phased out and .." remote agents will have an accurate way to discover the inherent type of resources without sniffing and without downloading the file. Yet authors will still have a way to treat the same resource in different ways without resorting to hard links or symbolic links and the like (so resources maintain a one-to-one mapping with URIs)
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
This bug was cloned to create HTML WG bug 19014. http://esw.w3.org/topic/HTML/LinkAndEmbeddingAttributes
Upon further investigation, I think it's unlikely that allowing authors to arbitrarily override the MIME type of files loaded into <iframe> is a good idea. It's already kind of possible for <object> (and with <img> it's irrelevant), but it's so massively complicated there that I don't think it's something we should try to replicate. But I have to be honest, I don't really understand the original request. I'm marking this NEEDSINFO. The information I need is a clear description of the problem that needs solving, and an analysis of the security implications (see comment 7).