[imports]: The dedup behavior with redirects should be clarified. (bugzilla: 25818)

[hayatoito]

Title: [imports]: The dedup behavior with redirects should be clarified. (bugzilla: 25818)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25818

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25818#c0
Morrita Hajime wrote on 2014-05-19 23:17:16 +0000.

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 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.

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25818#c1
Anne wrote on 2014-05-20 08:01:03 +0000.

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.

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25818#c2
Morrita Hajime wrote on 2014-05-22 23:59:56 +0000.

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 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...

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25818#c3
Anne wrote on 2014-05-23 06:25:46 +0000.

If we're fetching the same URL, as in:

# 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.

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25818#c4
Ian 'Hixie' Hickson wrote on 2014-05-23 20:27:51 +0000.

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?

---

comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25818#c5
Anne wrote on 2014-05-26 09:36:16 +0000.

Does CSS do anything here with @import-(this-is-inserted-to-avoid-notification-in-migration) that can we learn from?

---

comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25818#c6
Tab Atkins Jr. wrote on 2014-05-27 00:36:34 +0000.

(In reply to Anne from comment #5)

Does CSS do anything here with @import-(this-is-inserted-to-avoid-notification-in-migration) that can we learn from?

Nope.

[TakayoshiKochi]

This has been open without any discussion for some time, and as HTML Imports spec is no longer actively maintained, closing this without any conclusion.