Issue metadata
Sign in to add a comment
|
Cache storage fails beyond 256mb |
||||||||||||||||||||||
Issue description
Trying to store responses larger than 256mb causes an "unexpected internal error".
const response = new Response('a'.repeat(1024 * 1024 * 256));
caches.open('test').then(c => c.put('whatever', response)).then(
() => console.log('done!'),
err => console.error('failed', err)
);
Demo: https://jsbin.com/bamumi/edit?js,console
,
May 9 2018
nit: that example creates a 512MB response (since strings use 16-bit chars in javascript). I also wonder if it only fails with responses creates from strings, or also for other responses?
,
May 9 2018
I actually reported the bug to Jake. I did download real files from a server and gradually increased the MB to test how big they can become. And during that testing I found that files with a size < 255MB work perfectly, when they get 256MB and bigger I get the strange error message as reported
,
May 10 2018
I have created a simple demo HTML for this issue. It does not only occur for in-memory Response bodies, but also for Response bodies that are File objects (from a file picker, ie., the user's hard disk) or Blob instances that can be retrieved from Chrome's proprietary FileWriter API. 256 MB seems like a magic number that is deliberately put in. The "unexpected internal error" seems to support this assumption.
,
Aug 8
This still reproduces. I investigated and its a limitation of the simple disk_cache backend. See: https://cs.chromium.org/chromium/src/net/disk_cache/simple/simple_backend_impl.cc?l=301&rcl=880ba3d357766f3a3435be3f24603b765e6a359c Which does: return static_cast<int>(index_->max_size() / kMaxFileRatio); Cache API sets max_size() to effectively INT32_MAX. kMaxFileRatio is hard coded to 8. 2GB / 8 = 256MB. There are some other issues with the simple disk_cache as well. I'll take this issue into account when refactoring the internals.
,
Aug 8
Actually, let me take this since its related to the refactoring work on my plate.
,
Aug 24
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jakearchibald@chromium.org
, May 7 2018