This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It can be that I'm overlooking something, but I don't see answers for these questions in the spec: - what about data urls? are they allowed? and blobs? - what about HTTP error pages? (is redirection allowed?) - what about response other than text/html? - should we be able to stop external resource loading for only one import (and it's subtree) or only for the whole master document?
1 and 2 should be clear from using Fetch.
After talking to Anne, I think I got all my questions answered... so I'm closing this for now.
It would help bug-followers to see the resolution in detail. IOW, for each hyphen-bulleted point in comment 0, a resolution item. Thanks, /be
We should probably actually clarify data URLs. I suspect they should not be allowed here as they would be able to execute scripts. I need to add the flag proposed by Jonas in http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0696.html and HTML imports should probably not set it. Is the text/html requirement stated? Brendan, as for the rest: * blob URLs can work if they're same-origin * redirect should be followed http://fetch.spec.whatwg.org/#atomic-http-redirect-handling * HTTP response status should probably be ignored (we never pay attention to it) * only text/html should be allowed (is that stated in the specification now?) * stopping of external resource loading is up to the UA mostly (unless there's explicit API which there's not)
(In reply to Anne from comment #4) > We should probably actually clarify data URLs. I suspect they should not be > allowed here as they would be able to execute scripts. I need to add the > flag proposed by Jonas in > http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0696.html and > HTML imports should probably not set it. Why is script execution a concern exactly? I also don't quite get the example from Jonas, since data urls should only work if the redirect count is 0, no? > > Is the text/html requirement stated? > It is not actually, the spec only states that the default type is text/html. I really think it should be. One more thing that came up is if import documents fire their own load event or not. Also the spec mentions a simple load event fired against the referring links, but I'm not absolutely sure if that is a DOMContentLoaded or a Document load kind of event, in terms of when to fire. Should we wait for images for example in the import before we fire it? (In reply to Brendan Eich from comment #3) > It would help bug-followers to see the resolution in detail. IOW, for each > hyphen-bulleted point in comment 0, a resolution item. Thanks, > > /be I think I closed this bug prematurely, also, this request is perfectly valid, sorry about that. And thanks Anne for doing the work for me :)
(In reply to Gabor Krizsanits from comment #5) > Why is script execution a concern exactly? We want to restrict data URLs more. Them simply inheriting the origin of the fetching context can be somewhat dangerous. Not a 100% sure whether this applies to HTML imports, as they can effectively do the same as <script> which is also unprotected. Seems like http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0729.html is the larger issue here.
(In reply to Anne from comment #4) > * HTTP response status should probably be ignored (we never pay attention to > it) Is that right? <img> ignores it but <object> doesn't. I don't know about other features.
Moved to https://github.com/w3c/webcomponents/issues/207