[Webkit-unassigned] [Bug 257327] Old url hash fragment is used when loading page from cache

[bugzilla-daemon at webkit.org]

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

Chris Dumez <cdumez at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cdumez at apple.com

--- Comment #2 from Chris Dumez <cdumez at apple.com> ---
I have a decent idea of where the issue may reside.

The key we use the network cache ignores the URL hash (which is intentional as pages with different fragments normally have the same bytes):
```
Key Cache::makeCacheKey(const WebCore::ResourceRequest& request)
{
    // FIXME: This implements minimal Range header disk cache support. We don't parse
    // ranges so only the same exact range request will be served from the cache.
    String range = request.httpHeaderField(WebCore::HTTPHeaderName::Range);
    return { request.cachePartition(), resourceType(), range, request.url().stringWithoutFragmentIdentifier(), m_storage->salt() };
}
```

However, we also cache redirects in the cache and I think caching redirects with fragments may lead to confusion:
```
std::unique_ptr<Entry> Cache::makeRedirectEntry(const WebCore::ResourceRequest& request, const WebCore::ResourceResponse& response, const WebCore::ResourceRequest& redirectRequest)
{
    auto cachedRedirectRequest = redirectRequest;
    cachedRedirectRequest.clearHTTPAuthorization();
    return makeUnique<Entry>(makeCacheKey(request), response, WTFMove(cachedRedirectRequest), WebCore::collectVaryingRequestHeaders(networkProcess().storageSession(m_sessionID), request, response));
}
```
because the response coming from the cache contains a fragment (and it may not match the one of the request)

So we when we navigate to https://www.monzo.com/#foo=bar, we cache an entry with the key "https://www.monzo.com/#foo=bar" which is a redirect to https://monzo.com/#foo=bar. Then later on, we try the load https://www.monzo.com/#bar=foo, we look up the same cached redirect, since we ignore the fragment in the request and end up redirecting the the cached destination URL (https://www.monzo.com/#foo=bar).

-- 
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/20230530/2490832e/attachment-0001.htm>