Repository navigation
Maximum file size that cache should support #1770
Description
The caching mechanism, utilizing cache.add() and cache.addAll(), does not currently enforce a size limitation on files being added.
Historically, this posed no major issue as typical use cases did not involve extremely large files.
Recently, however, the use of caching for Large Language Models (LLMs) has led to attempts to cache files larger than 2 GB.
For example, Chrome has a bug on opening 2 GB+ file in CacheStorage: https://crbug.com/391398191
It's not realistic to support infinite size, so it would be beneficial to specify a size limitation.
My proposal would be around 100 - 200 GB.
Activity
yoshisatoyanagisawa commentedon May 19, 2025
There seems not be a maximum size per response stored in the cache storage. However, it sounds nice to have the limitation per cached response size.
The actual size should be discussed upon the feasible sizes chosen per existing implementation, operating systems, and underlying libraries or middleware.
@elkurin Will you elaborate more on why you propose 100-200 GB limitation? Lower limit might come from the existing applications, and upper limit might come from OS limitations or so, but I would like to understand more details.
@domenic @annevk @youennf @asutherland Can I ask your thoughts?
annevk commentedon May 19, 2025
It seems to me that if this is a drastically increased an end user will much sooner arrive at the point where temporary storage needs to be cleared by their user agent, potentially nullifying the benefit.
domenic commentedon May 19, 2025
I'm unsure if this should be tackled for cache storage specifically, or if it should instead be tackled more holistically for all storage types on the web platform.
asutherland commentedon May 19, 2025
I agree with @domenic that this should probably be addressed more broadly (probably in the storage spec?), but I do want to recognize 2 issues raised here:
uint32_tandint32_tthresholds and it would be great to have tests to help implementations identify these bugs. It seems like this might be more consistent with spec language saying files of 4GiB + 1 bytes must be supported.elkurin commentedon May 20, 2025
About the size limitation, 4GB is one obvious choice considering int32_t maximum size, but might be not enough considering we already have 2GB+ usage.
In the existing Chromium implementation, we support ~256GB (while it has some bug still) ref.
We rounded up to 256 bytes blocks to hold ~256GB values in int32_t where we picked 256 bytes as a common alignment.
So, I proposed 100~200 GB as somewhat satisfying and supportable size.
Tests are another concerns. As @asutherland pointed out, tests with large file s not ideal, and also it won't fit in the maximum time duration in WPT.
Anyway, I opened a new issue in storage spec: whatwg/storage#181. Sounds better to continue discussion there.
elkurin commentedon May 27, 2025
cc-ing @fergald
fergald commentedon May 28, 2025
I don't think allowing large files will have much impact on total temporary space used. People are already caching them, just in a non-ergonomic way, e.g. using blobs in IndexedDB or breaking them into chunks. See e.g. https://developer.chrome.com/docs/ai/cache-models .
Given that it's a legit and increasingly common thing to do, we should make it ergonomic. I am slightly concerned that it becomes easy to accidentally use a huge amount of space but it's not like there are lots of URLs out there that will unexpectedly yield a 10G response.
The rise of these huge files means that browsers should have better UIs for managing and tidying disk space. Ensuring that these files are in
CacheStorage, associated with their original URL allows for better UX. They are much more deleteable (or preserverable) than if they were stored as a blob in IndexedDB or broken into chunks in OPFS.