Is it possible to use Cache-Control headers to control Deno's cache
I've seen via an issue ( https://github.com/denoland/deno/issues/16296 ) that Deno stores its metadata.json files in its cache directory so that it has response headers from when the dependency was downloaded, for cache invalidation. Is there cache invalidation based on these headers? Like if I have a dependency via HTTP that has Cache-Control: no-cache, can it be re-downloaded each time it's requested?
GitHub
deno cache: add option: deterministic · Issue #16296 · denoland/de...
avoid the "make deterministic DENO_DIR" workaround in #16295 let me call deno cache --deterministic --lock=lock.json --lock-write main.ts to produce $DENO_DIR/deps/*/.metadata.json file...
2 Replies
The documentation does not provide a clear answer to your question about whether Deno's cache invalidation is based on response headers such as
Cache-Control: no-cache. It does mention that Deno caches all remote imports in a global cache directory on your system, and that this cache is used for subsequent runs of your program. However, it does not specify whether this caching behavior is influenced by HTTP response headers.
The documentation does mention the use of Cache-Control headers in the context of Deno Deploy's compression feature. Specifically, it states that Deno Deploy will skip compression if the response’s Cache-Control header has a no-transform value. But this is not directly related to your question about Deno's caching of module dependencies.
If you're experiencing a technical issue related to this, it might be helpful to try clearing Deno's cache using the deno cache --reload command, or specifying certain modules to be reloaded with deno cache --reload=<module_url>. If the issue persists, you might want to consider asking for help in the Deno community or filing an issue on the Deno GitHub repository. 🦕Someday, AI helper, someday you'll be useful