It looks like a problem with WorkerScriptLoader and MemoryCache.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

(blink-worker triaging) I guess nothing has changed. Changed the status as Available.

RawResources are not stored in MemoryCache recently and this is working as intended.

Is there any way we can change this? 

The current state is very confusing and frustrating for developers. Workers are often used to do heavy lifting and as such load a good amount of code. Some use-cases even load the same worker code multiple times to distribute the workload. Not respecting caching headers means the user will download the same payload multiple times.

Frameworks are projected to move a lot of logic to workers in the near future and I think it’s crucial that caching headers work as with any other resource. (Also I am wondering: Is not respecting caching headers on workers even spec compliant?)

I don't think this should be a WontFix. https://www.w3.org/TR/workers/ section 4.4 part 5 says that the result is from a fetch, and fetches IIRC honor caching headers. 

Also it's a bit of a gotcha for any developer who thinks they've set caching headers appropriately, only to find that in this case they aren't honored.

More concretely the fetch spec https://fetch.spec.whatwg.org/#http-network-or-cache-fetch 2.20.1 does seem to expect that caching is honored.

I'm struggling to recreate this.

Demo: https://worker-cache-test.glitch.me/

Here, the worker logs a random number each time it's fetched.

If I start up a worker, then start up another, I get the same random number (it appears to be using the same worker).

If I clear the cache and start up two workers at once, they both seem to have the same random number too.

What am I missing?

Ah, so I am sending multiple requests for the same worker at the same time.
With fetch we coalesce these kind of requests. I’m guessing that’s what makes the difference?

Here’s my glitch for comparison: https://crbug-688421.glitch.me/

Pressing “Load two worker instances” in Jake’s demo shows the same behavior. So this is not about respecting cache headers per se, but when there’s multiple requests in flight for the same worker resource.

For comparison, we do block on the first request and re-use if appropriate with fetch() and iframes: https://docs.google.com/spreadsheets/d/18N8Z44Z9446KHWt-8-HKH6pi5UY25wjaBCgndVFOAI4/edit?usp=drive_web&ouid=110294449713434599244

Shoul

Are you talking about the memory cache or the disk cache? Requests initiated by fetch() are not stored in the memory cache.

It seems like the problem might be me. It works in incognito.