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 27 users Project Member Reported by, Jan 29 2015 Back to list
Status: Started
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 2016
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 #c17 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.
Project Member Comment 24 by, Apr 12
The following revision refers to this bug:

commit 8a82f1f36590e504b12f486df6351e78ca223097
Author: yiyix <>
Date: Wed Apr 12 15:28:12 2017

Fetch API: Add Request#cache attribute

Behind the run time flag FetchRequestCache, a new attribute |cache|
is added into fetch request. Cache can be set to "default", "no-store",
"reload", "no-cache", "force-cache" or "only-if-cached". Please refer
to for exact definition.
Note that the implementation of cache options are not completed yet.



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


Labels: -Hotlist-Recharge
Owner: ----
Status: Available
Should we assign this to yiyix@ or it's supposed to be taken over by someone else in Tokyo?
Status: Started
I think yiyix@ is still working on this, assigning for now.
yiyix any updates or would it be better to revert this to available to avoid creating confusion about the state of this FR?
After returning to my home office after chrome envoy, I took a break on this implementation. I resumed working on this this week. If this is urgent, feel free to assign to other people. I will report my status here. 
Sign in to add a comment