Closed Bug 1471297 Opened 2 years ago Closed Last year

fetch() and importScripts() do not share HTTP cache


(Core :: Networking: Cache, defect)

60 Branch
Not set



Tracking Status
firefox61 --- affected
firefox62 --- affected
firefox63 --- affected


(Reporter: nolan, Unassigned, NeedInfo)



(4 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134

Steps to reproduce:

1. Open Fiddler on Windows (or equivalent network tracker on another OS)
2. Navigate to in Firefox
3. Wait 5 seconds

Actual results:

library.js is downloaded twice.

Expected results:

library.js should be downloaded once. The page is running this code inside of a web worker:

fetch('library.js').then(() => {
  /* wait 5 seconds */

In Chrome and Edge, this only downloads library.js once. In Firefox, it downloads twice.

I also tried a workaround by explicitly setting the fetch Request destination to "script", but this also downloads twice in Firefox:

This bug is important because we have a web team at Microsoft that is using "fetch then importScripts()" as a way to prewarm the cache. (This team prefers not to use link rel=preload because 1) this requires a round trip back to the main thread, and 2) dynamic link rel=preload is not supported in Firefox: )
Hi Nolan, 

 I can reproduce this issue on the current release build 61.0 and also on the latest Nightly 63.0a1 (20180628220051).

Thanks for reporting!
Component: Untriaged → Networking: Cache
Ever confirmed: true
Product: Firefox → Core
Nolan, I can't reproduce using your bl.ocks site.  See attached output from devtools.  This was after reloading the page a couple times so the resources were already in cache.

Can you try with a clean profile?
Flags: needinfo?(nolan)
Or are you saying network connections are produced even through its pulling from http cache?
Right, I'm saying that from the server's point of view, there are two requests for the resource instead of one. (This is assuming a clean cache, so PLT1.)
Flags: needinfo?(nolan)
Using `python -m SimpleHTTPServer` to serve your example I don't see any additional request.  Maybe its using different headers than your production system, though?

I guess I'll defer to the http cache folks on this.  I don't think I've been able to reproduce it, though.
> Using `python -m SimpleHTTPServer` to serve your example I don't see any additional request.

I mean, the python server does not see any additional request.
It does reproduce cleanly on 63.0a1 (2018-07-01) (64-bit) on Manjaro 17.1.10 Hakoila.
Attached image Screenshot (2).png
Reproducible on firefox 60.0.2 (64-bit) running on Windows 10, version 1803.
Those screenshots say "cached" which means it satisfied the request from http cache and not a server request.  They don't demonstrate the comment 0 report AFAICT.
Hm, I just tested Firefox 61.0 on Windows 10 RS4 (1803) and I can no longer reproduce; I see the same behavior in Chrome, Edge, and Firefox. Note that I'm using Fiddler as the source of truth here, to confirm whether a second request is being made. I used the bl.ocks site though.

Not sure what needs to be done to make this consistently reproducible. :/
It could be due to racing cache with network, i.e. if the disk is too slow we might get the resource from the network faster. We would see the reason from the log ( Please, provide a log of page load when you see the problem.
Flags: needinfo?(nolan)
Also note, default fetch() credentials mode changed from omit to same-origin in FF61.  I believe importScripts() sends cookies.  Perhaps http cache was partitioning anonymous connections from credentialed connections in older versions?
Nolan, Marking as WORKSFORME as per your comment #10. If you can reproduce the bug again, feel free to reopen the bug, thanks.
Closed: Last year
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.