New issue
Advanced search Search tips

Issue 920146 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 3
Type: Bug

Blocked on:
issue 886861



Sign in to add a comment

cache_storage could detect response body corruption

Reported by d...@yandex-team.ru, Jan 9

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3667.0 Safari/537.36

Steps to reproduce the problem:
1. Open this SW example https://mdn.github.io/sw-test/
2. Go to user profile -> Default -> Service Worker -> CacheStorage -> 96c4eadbecef927755015636c1b3e57fadb5aef9 -> d71afd2b-d308-4b43-b696-fd5a2cbe1226
3. Modify some bytes in 60f15e88743973ef_0 (it corresponds to "snowTroopers.jpg" file) using any hex editor
4. Refresh the page

What is the expected behavior?
caches.match catches checksum mismatch in the corrupted file and resolves a promise with an error

What went wrong?
caches.match resolves the promise with the corrupted Response

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 73.0.3667.0  Channel: n/a
OS Version: 
Flash Version: 

Seems like caches.match should check the Response for errors before passing it further.
 
Components: Blink>Storage>CacheStorage
Labels: OS-Android OS-Chrome OS-Fuchsia OS-Mac OS-Windows
This sounds like a feature request... I'm not sure detecting corruption is expected. It may make sense to match the http cache, does that cache do this?
Components: -Blink>ServiceWorker
Labels: Needs-Triage-M73
Blockedon: 886861
Labels: -Pri-2 Pri-3
Summary: cache_storage could detect response body corruption (was: caches.match can be resolved with corrupted response)
Its unlikely we would ever implement detecting corruption before cache.match() resolves its promise.  That would require reading the entire body blob in order to checksum it.

What we could possibly do in the future is catch errors while reading the body data and produce an error during the read operation.  For example, I believe the firefox cache_storage implementation would produce an error while reading the body because decompression would fail.  If we implementation compressed bodies we would get something similar or we could implement a checksum that is verified if the entire body is read.
Labels: -Needs-Triage-M73
Could we at least not put an entry to the cache until all the data has been written to disk? That's how http cache works (as I know).
Status: Available (was: Unconfirmed)

Sign in to add a comment