[Webkit-unassigned] [Bug 244000] New: NetworkCache uses URL instead of URI as a part of caching key

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=244000

            Bug ID: 244000
           Summary: NetworkCache uses URL instead of URI as a part of
                    caching key
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: History
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cathiechen at igalia.com

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/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220816/5d64ea2c/attachment.htm>