Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 453190 Support fetch() cache control options.
Starred by 23 users Project Member Reported by, Jan 29 2015 Back to list
Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

issue 455093
issue 652994
issue 451664

Sign in to add a comment
request.cache was introduced in the Fetch API spec.

But Chrome doesn't support it yet.
There is a privacy concerns about this cache parameter.

When this concerns will be solved, we should support it.

Comment 1 by, Jan 29 2015
Blocking: chromium:451664
Blocking: chromium:455093
Labels: Cr-Blink-Fetch
Comment 4 by, Apr 16 2015
Labels: -Cr-Blink-ServiceWorker
Any update on this one? I'm going to remove SW now that Fetch is exposed on window.
No update, and it's OK to remove the label.

Comment 6 by, May 7 2015
Issue 484485 has been merged into this issue.
Comment 7 by, Aug 5 2015
Labels: -Cr-Blink-Fetch Cr-Blink-FetchAPI
Sorting out the privacy question.
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

Comment 10 by, Sep 24 2015
I wanted to point out that and increasingly common pattern I'm seeing "in the wild" is folks who use service workers to precache a list of resources as part of the oninstall handler, and then use a cache-first policy to serve responses in their onfetch handler.

The problems lie when a resource changes—let's say that the developer bumps a cache versioning string embedded in the service worker script, triggering another oninstall handler. It's very important that the HTTP requests used to repopulate the Cache Storage API cache go against the network and not the browser's HTTP cache at this point, because if it hits the browser's HTTP cache, that stale response will be reused in the subsequent cache-first onfetch handler, defeating the purpose of cache versioning.

Right now, one workaround is to append cache-busting URL parameters when requesting resources prior to using a cache-first onfetch handler, but that's a kludge. Much cleaner would be if `new Request('', {cache: 'reload'}))` worked as documented.

(Bonus points if, down the line, there were an easy way to get cache.addAll([urlString1, urlString2, ...]) to use {cache: 'reload'} for each Request it constructs, but that's a different issue outside the scope of this bug.)

You can see an example of what the current, kludgy best practice looks like at
Comment 11 by, Nov 27 2015
Labels: -Cr-Blink-FetchAPI Cr-Blink-Network-FetchAPI
Comment 12 by, Jan 25 2016
Issue 451664 has been merged into this issue.
We might want to give this a higher priority. Although it's performance anti-pattern to bypass the cache in SW updates, it's being pointed to externally as a service worker failure :(
FWIW I'm working on implementing this in Firefox right now.  If everything goes well, I should have patches up for review this week, so it will be likely that we ship this in Firefox 47 or 48 at the latest.
Status: Assigned
Given #10 #13 and #14 we should prioritize this higher. And also FetchEvent.request.cache. Related, FetchEvent.request.isReload is going away from the spec and we'll need that implemented to have an alternative.

Would the network API team be able to take this? Assign to tyoshino for triage.
Let's start implementation. only-if-cached would be restricted to same-origin only initially.

This came up at the F2F in the context of

Seems like developers wants this (the .cache in particular).
Can someone take ownership?
Blocking: 652994
Firefox implemented this:

Can we bump priority so we can start deprecating FetchEvent.isReload?
Implementation note: watch out for bug 627481, bug 579866, bug 648761 when implementing.
Project Member Comment 21 by, Oct 24
The following revision refers to this bug:

commit 6a97fb88d5ad4c437c60562d0083a87b898547a4
Author: shimazu <>
Date: Mon Oct 24 02:57:12 2016

Update expectations of imported/wpt/service-workers

As mentioned at and,
'[ Skip ]' in TestExpectations cannot be overwritten by WPTTestExpectations.
This patch changes '[ Skip ]' to '[ Failure ]' by default in TestExpectations
in order to run the w3c tests on WPTServe bots.

BUG= 602693 ,453190,624278,617886,571722, 618616 
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug imported/wpt/service-workers
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests --enable-wptserve -f -t Debug imported/wpt/service-workers

Cr-Commit-Position: refs/heads/master@{#427010}


Issue 688427 has been merged into this issue.
Sign in to add a comment