This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Reported from here: https://code.google.com/p/chromium/issues/detail?id=373331 The suggestion there is that The dedup should be done based on final, redirected URL. I don't support that idea as the URL given to <link> is what the author want. If the author requests different URLs, they should be loaded separately even if the final URL is same. Filing this bug to hear people who know underlying principle better.
Using response's url as suggested in that bug is probably better. E.g. if you consider something like HSTS you would probably want http://example.com/import and https://example.com/import to be treated as identical resources.
Thanks for the feedback, Anne. I wasn't aware of HSTS issue. At the same time I realized some shortcomings of response URL approach: * It means UA have to request fetching for each <link> element regardless there is (already) duped links, that makes de-dup no longer completely free. It could be cached but * UA needs some kind of interaction to fetch layer at least. * As import loading could be highly concurrent, same URL can be requested in parallel because we cannot see if these two results same URL. Also, we couldn't speculatively share the resource like images do because imported documents are mutable. Hmm...
If we're fetching the same URL, as in: <link rel=import href=/a id=a> <link rel=import href=/a id=b> #b can reuse an ongoing process for #a in Fetch. I need to explicitly allow that somehow (bug 25872). See step 10 of http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch for how we used to do this. I don't think you'd need deep interaction with the fetching layer. The moment you get back a response the whole resource has not yet been downloaded and at that point you could make decisions and maybe terminate that particular fetch.
I think it'd be a lot less confusing to dedupe based only on the URL as it is found in the markup. That way we can have deduped before we start fetching anything, and so we can even represent the final resource dependency tree in the DOM somehow. If we wait until we've actually fetched stuff over the network to work out what the dependencies are, we're going to have all kinds of weird effects. This is particularly relevant, for example, when it comes to dependencies outside of imports. For example, if we add dependencies to <script> with deduping, consider something like the following: <script ... src="a.js"></script> <script ... src="b.js" needs="a.js"></script> <script ... src="c.js" needs="b.js"></script> <script ... src="d.js"></script> <script ... src="e.js" needs="d.js"></script> (Assume the stuff in "..." is something that makes this dedupe and delay loads until the resources are needed.) It looks simple: when you need c.js, you can immediately set of setches for a.js and b.js. But what if b.js actually resolves to e.js? Now what do we do? Do we now fetch d.js and throw away a.js? Do we still run a.js? What if later we try to run the e.js script? Is it deduped to the b.js script? Does d.js ever run?
Does CSS do anything here with @import that can we learn from?
(In reply to Anne from comment #5) > Does CSS do anything here with @import that can we learn from? Nope.
Moved to https://github.com/w3c/webcomponents/issues/209