ServiceWorker Cache API fails to observe correct Vary behavior
Reported by
abe...@fastly.com,
Aug 18 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 Steps to reproduce the problem: 1. Visit https://vary-test.fastlydemo.net/#sw-cache 2. Wait for SW install (maybe 5 sec) 3. Soft-refresh 4. Observe failure reports What is the expected behavior? According to https://w3c.github.io/ServiceWorker/#query-cache-algorithm, the cache API should be storing and validating a request against multiple stored variations. Therefore, I expect that I can store multiple variations of the same URL in the cache at the same time. What went wrong? It appears that only one variation is stored in the cache, and the Vary header is treated as a validator, in a way similar or possibly identical to the HTTP network cache. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 60.0.3112.90 Channel: n/a OS Version: OS X 10.12.6 Flash Version:
,
Aug 23 2017
,
Aug 24 2017
Wow, thank you so much for such a fantastic repro of this juicy interop bug!
Not sure how to prioritize, we partly respect the vary header by correctly validating the header when matching to a response, but we fail to cache multiple variants.
There are some notes about this limitation in the README.md file.
## Layout of the disk_cache::Backend
A cache is represented by a `disk_cache::Backend`. The Request/Response pairs
referred to in the specification are stored as `disk_cache::Entry`s. Each
`disk_cache::Entry` has three streams: one for storing a protobuf with the
request/response metadata (e.g., the headers, the request URL, and opacity
information), another for storing the response body, and a final stream for
storing any additional data (e.g., compiled JavaScript).
The entries are keyed by full URL. This has a few ramifications:
1. Multiple vary responses for a single request URL are not supported.
2. Operations that may require scanning multiple URLs (e.g., `ignoreSearch`)
must scan every entry in the cache.
*The above could be fixed by changes to the backend or by introducing indirect
entries in the cache. The indirect entries would be for the query-stripped
request URL. It would point to entries to each query request/response pair and
for each vary request/response pair.*
,
Sep 2 2017
This one's a real good compat feature request
,
Sep 2 2017
,
Sep 5 2017
Issue 641948 has been merged into this issue.
,
May 29 2018
,
Jul 31
,
Jul 31
,
Jul 31
I plan to work this, but I want to investigate a few more issues first. Since this may be more of an architectural change I want to make sure it takes into account other problems as well.
,
Jul 31
,
Jul 31
Hey! Welcome to Chrome! This issue is discussed briefly in the *README as well. Happy to VC with you sometime to go over the history and design of Chrome's CacheStorage if it would help. *https://cs.chromium.org/chromium/src/content/browser/cache_storage/README.md
,
Aug 14
,
Sep 19
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by krajshree@chromium.org
, Aug 22 2017Labels: Needs-Triage-M60 M-62 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
232 KB
232 KB View Download