Issue 643111  has been merged into this issue.

dalecurtis@, the devtools "disable cache" has mechanisms to handle disk cache and memory cache, but it appears we don't have the media cache covered. Is there a disable/clear mechanism for the media cache that'd make sense for web developer usecases?

+allada on the devtools side.

We should integrate this setting into the local media cache somehow.

The original issue (643111) stated that the cache isn't cleared even if you restart chrome, which would mean that the media cache isn't the (only) issue.
Is this still the case?

This seems a bit tricky to fix.

What I'm trying to do is to make sure that we don't re-use data from the url_index cache if the "disable cache" button is checked. However, uf I'm reading the code right, the no-cache header is added in a devtools javascript callback, and there doesn't seem to be an easy way for us to detect the state of the "disable cache" button, or even notice the presence of the no-cache http header.

I will keep digging.

allada, can you provide some pointers on how "Disable cache" is sent to the backend?

Any updates on this? Have there been any changes to the mechanism by which the media cache can be informed of the "disable cache" setting?

A second request made in a new tab in a non-private window with the 'disable cache' option checked in the (open) dev tools does not use the cache for media. I don't know if that's a coincidence or if that option is working sometimes.

It's not a coincidence.
For media, there are two caches in in chrome: One is the regular HTTP disk-based cache which is used for all requests. The second one is a per-tab, in-memory cache.  The in-memory cache is the one that doesn't understand the "Disable cache" checkbox. But because it's in memory and per-tab, closing the tab, or using a different tab will work around it.

"Disable Cache" + MemoryCache is implemented in two points:
1. When "Disable Cache" button is pressed, MemoryCache is cleared, in InspectorNetworkAgent::setCacheDisabled():
https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/core/inspector/InspectorNetworkAgent.cpp?type=cs&l=1449
2. When a new request is about to be sent, ResourceRequest's CachePolicy is set to kBypassingCache or alike:
https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/core/inspector/InspectorNetworkAgent.cpp?type=cs&l=709

Implementing similar things in media cache might work.

> Comment #6
> the no-cache header is added in a devtools javascript callback, and there doesn't seem to be an easy way for us to detect the state of the "disable cache" button
So checking ResourceRequest::GetCachePolicy() might be another option.

As for merging (a part of) media cache control mechanism into MemoryCache:
Discussed offline briefly but I haven't figure out clear vision for this.
Some high-level random thoughts:
- Integrating caching mechanisms and having a single point of cache reuse control within Blink is good. However, if merging makes MemoryCache much complex, I'd like to avoid that, because MemoryCache is a key part for ensuring CORS and other security-related correctness, and complex MemoryCache policy causes security bugs.
- Not sure whether the caching policy of media cache and MemoryCache are well suited with each other. MemoryCache is mainly for handling HTTP+CORS caching correctness and some Blink-side specific conditions. For images, MemoryCache has a special condition that allows reusing images within a page even with no-cache (which has justification in the HTML spec). If we can implements the media cache policy similarly by a simple special rule, then the things might be easy.
- Another issue is RawResource is becoming and going to be non-reusable (driven by security reasons). If we naively merge media cache to MemoryCache, we'll reuse RawResource (instead of creating separate RawResources that are served by the same data in the media cache), but probably this is not preferable. Perhaps we might have to create a new type of Resource, say, MediaResource, and migrate media cache reuse semantics into that?

Anyway I'm not familiar with media code. I'll read more code and revisit this.

+Blink>Loader if someone is interested in organizing multiple caches in Blink.

To add some info from what I've found:

This is the cache class (UrlIndex) causing problems in this bug in media:
https://cs.chromium.org/chromium/src/media/blink/url_index.h?q=url_index&sq=package:chromium&l=216

What hubbe@ and I talked about, letting MemoryCache control the lifetime of the cache and invalidations seems like the most appropriate thing to do. This would allow devtools (or wherever that needs to purge cache) have a single cache API interface.

From my conversation with hiroshige@, the idea seemed like a good idea, however like hiroshige@ stated above the complexity is the battle.

However we go about doing this a design doc seems like the best thing to do at this point.

Hey everyone. DevRel are getting some public interest on this feature again. Is there any progress and/or timeline you can share with me?