Per [1], the key is composed of, at a minimum, the request method and target URI. But in NetworkCache, Cache::makeCacheKey uses URL instead. We have a test to reproduce that the cache does not work: - Open [2] and click the button to add fragment to the URL, then click the link on the page. - Terminate safari and reopen it. - Hit back button. The page is downloaded from network instead of disk. Because the browser is terminated, there is no page cache after reopen. Then it goes to network process to get the data, it checks the NetworkCache first, but there is no entry found for the key does not match. It stores by "https://perfect-lively-xylophone.glitch.me/", but when retrieve, the key is "https://perfect-lively-xylophone.glitch.me/#somefragment". Not sure if we could treat this key same as the http cache[1], but "fragment identifiers are reserved for client-side processing". Looks like the cache should be reused. [1] https://httpwg.org/specs/rfc9111.html#caching.overview [2] https://perfect-lively-xylophone.glitch.me/
Created attachment 461679 [details] WIP-patch Upload a WIP patch which use url().stringWithoutFragmentIdentifier() instead of url() as the key.
This seems like a reasonable change, but needs a test.
There may be something in LayoutTests/http/tests/cache that is similar to a test we would want for this.
Pull request: https://github.com/WebKit/WebKit/pull/3458
(In reply to Alex Christensen from comment #3) > There may be something in LayoutTests/http/tests/cache that is similar to a > test we would want for this. Thanks a lot, Alex! I added a function to generate fragment in LayoutTests/http/tests/cache/disk-cache/resources/cache-test.js Please take a look at the pull request:)
Committed 253567@main (d62692ae68ab): <https://commits.webkit.org/253567@main> Reviewed commits have been landed. Closing PR #3458 and removing active labels.
<rdar://problem/98841865>