257327 2023-05-25 06:25:57 -0700 Old url hash fragment is used when loading page from cache 2023-05-30 13:49:05 -0700 1 1 1 Unclassified WebKit Page Loading Safari 16 All All RESOLVED DUPLICATE 255924 https://bugs.webkit.org/show_bug.cgi?id=255924 P2 Major --- 1 saralkaushik webkit-unassigned achristensen beidson brandonstewart cdumez koivisto oldest_to_newest 1957893 0 saralkaushik 2023-05-25 06:25:57 -0700 Steps to reproduce... 1. Go to a URL that performs a 301 redirect, with a hash in the URL. E.g. https://www.monzo.com/#foo=bar 2. Observe that the user is redirected to https://monzo.com/#foo=bar 3. Go to a URL at a completely different domain name 4. Go to the same URL in step 1, but with a different hash https://www.monzo.com/#bar=foo Expected Results The user should be redirected to https://monzo.com/#bar=foo Actual Results The user is redirected to the URL from step 2, e.g. https://monzo.com/#foo=bar 1958218 1 ap 2023-05-26 09:37:53 -0700 Is this the same as bug 255924? 1958870 2 cdumez 2023-05-30 13:41:35 -0700 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). 1958872 3 brandonstewart 2023-05-30 13:44:26 -0700 This appears to be a duplicate of the issue I am working on. https://bugs.webkit.org/show_bug.cgi?id=255924 1958873 4 cdumez 2023-05-30 13:49:05 -0700 *** This bug has been marked as a duplicate of bug 255924 ***