Issue 831558  has been merged into this issue.

@Reporter: Please provide sample URL/test file to test this issue from TE end. Any further information on reproducing the issue would help in further triaging of the issue.

Thanks!

After a couple of more hours debugging, it seems to be a problem with the host... 

I put a repro up on github, but there it actually works. 
source: https://github.com/filipbech/filipbech.github.io/tree/master/demos/cache-keys
demo: https://filipbech.github.io/demos/cache-keys/

I tried two different local webservers where one works, and the other doesn't. (I screenshotted the response-headers, as I guess thats the only thing that is changed by that). 

I don't know if you still want to reproduce it, but my example doesn't work if you run it with this local server.. https://www.npmjs.com/package/local-web-server

Deleted: doesnt-work.png 237 KB

	doesnt-work.png 237 KB View Download

Deleted: works.png 231 KB

	works.png 231 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

That does seem to be a bug in our Cache implementation. 
Implementation bug details:
CacheStorageDispatcherHost::CacheImpl::Keys always creates a non-null request, even if the javascript code never passed a request to indicate it wants all the keys.
Since this request will have an empty url, our "query" code will ignore the url and return "all" the requests, except that it still tries to validate the Vary header (which as you might have noticed is the main difference between the working and non-working cases).

So a work-around would be to pass ignoreVary=true to keys(), and a solution would be for our implementation to not try to check the vary header if we have no request to compare it to (or maybe fix our keys implementation to not try to pass a request to our query implementation if no request was passed in in javascript).

Thanks for digging in Marijn. Seems like the fix is to make the mojo interface take an optional request and not pass a request if there isn't one. 

Started looking at this by writing a WPT:

https://chromium-review.googlesource.com/c/chromium/src/+/1156886

There is a deeper problem here.  It seems the simple cache backend does not actually store multiple entries for the same URL and different VARY headers.  See:

https://bugs.chromium.org/p/chromium/issues/detail?id=756796#c3

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c2c9ca2dbbdfa6f1636154898da23f7159d3a0cc

commit c2c9ca2dbbdfa6f1636154898da23f7159d3a0cc
Author: Ben Kelly <wanderview@chromium.org>
Date: Thu Aug 02 22:20:34 2018

Check cache.keys() when there are requests with VARY headers.

New test case added to existing cache-keys.https.html tests.

Bug: 831557
Change-Id: I26ba7b8fd616e4b7f9ab7382b42ef72c655dbfaf
Reviewed-on: https://chromium-review.googlesource.com/1156886
Reviewed-by: Victor Costan <pwnall@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580349}
[modify] https://crrev.com/c2c9ca2dbbdfa6f1636154898da23f7159d3a0cc/third_party/WebKit/LayoutTests/external/wpt/service-workers/cache-storage/script-tests/cache-keys.js
[add] https://crrev.com/c2c9ca2dbbdfa6f1636154898da23f7159d3a0cc/third_party/WebKit/LayoutTests/external/wpt/service-workers/cache-storage/serviceworker/cache-keys.https-expected.txt
[add] https://crrev.com/c2c9ca2dbbdfa6f1636154898da23f7159d3a0cc/third_party/WebKit/LayoutTests/external/wpt/service-workers/cache-storage/window/cache-keys.https-expected.txt
[add] https://crrev.com/c2c9ca2dbbdfa6f1636154898da23f7159d3a0cc/third_party/WebKit/LayoutTests/external/wpt/service-workers/cache-storage/worker/cache-keys.https-expected.txt