Maximum file size that cache should support

[elkurin]

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.

[yoshisatoyanagisawa]

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]

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]

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]

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:

1. It does seem likely for implementations to have bugs around uint32_t and int32_t thresholds 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.
2. Tests that do a ton of I/O, especially creating large files, really are unpleasant for automated testing runs because they tend to take a long time, be flaky, and/or be very unpleasant surprises for developers when running them locally. I know for Firefox/Gecko's automated quota testing about limits we adjust preferences so our quota limits are like ~10 MiB to test our logic, but that obviously won't shake out bugs that explicitly involve the maximum values of integer types. Does/could WPT have a concept of smoke/acceptance testing tests that are only run much less frequently? (I say that realizing that it's possible such tests would then never be run, defeating the point while also making people think there is test coverage...)

[elkurin]

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]

cc-ing @fergald

[fergald]

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.