- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Sep 2012 21:53:12 +0000
- To: public-html@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19014
Summary: Authors need more control over handling of embedded
resources
Product: HTML WG
Version: unspecified
Platform: All
URL: http://esw.w3.org/topic/HTML/LinkAndEmbeddingAttribute
s
OS/Version: All
Status: NEW
Keywords: NoReply
Severity: normal
Priority: P2
Component: HTML5 spec
AssignedTo: dave.null@w3.org
ReportedBy: contributor@whatwg.org
QAContact: public-html-bugzilla@w3.org
CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
public-html@w3.org, julian.reschke@gmx.de,
w3c@adambarth.com, aaz@odnorazovoe.ru
This was was cloned from bug 5776 as part of operation LATER convergence.
Originally filed: 2008-06-20 12:50:00 +0000
Original reporter: Rob Burns <rob@robburns.com>
================================================================================
#0 Rob Burns 2008-06-20 12:50:52 +0000
--------------------------------------------------------------------------------
* 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]
================================================================================
#1 Julian Reschke 2008-06-20 12:56:24 +0000
--------------------------------------------------------------------------------
How is this different from issue 5773?
================================================================================
#2 Rob Burns 2008-06-20 16:51:55 +0000
--------------------------------------------------------------------------------
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.
================================================================================
#3 Ian 'Hixie' Hickson 2008-06-20 17:27:39 +0000
--------------------------------------------------------------------------------
So this is a request for a way to override the type of a resource in an
<iframe> from the HTML side?
================================================================================
#4 Rob Burns 2008-06-23 16:14:58 +0000
--------------------------------------------------------------------------------
(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.
================================================================================
#5 Ian 'Hixie' Hickson 2008-06-23 18:56:39 +0000
--------------------------------------------------------------------------------
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.
================================================================================
#6 Rob Burns 2008-06-23 21:17:39 +0000
--------------------------------------------------------------------------------
(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
================================================================================
#7 Adam Barth 2008-06-23 23:17:19 +0000
--------------------------------------------------------------------------------
(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.
================================================================================
#8 Rob Burns 2008-06-24 07:36:58 +0000
--------------------------------------------------------------------------------
(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)
================================================================================
#9 Maciej Stachowiak 2010-03-14 13:14:23 +0000
--------------------------------------------------------------------------------
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.
================================================================================
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 25 September 2012 21:53:14 UTC