Bug 257327

Summary:	Old url hash fragment is used when loading page from cache
Product:	WebKit	Reporter:	saralkaushik
Component:	Page Loading	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED DUPLICATE
Severity:	Major	CC:	achristensen, beidson, brandonstewart, cdumez, koivisto
Priority:	P2
Version:	Safari 16
Hardware:	All
OS:	All
See Also:	https://bugs.webkit.org/show_bug.cgi?id=255924

Description saralkaushik 2023-05-25 06:25:57 PDT

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

Comment 1 Alexey Proskuryakov 2023-05-26 09:37:53 PDT

Is this the same as bug 255924?

Comment 2 Chris Dumez 2023-05-30 13:41:35 PDT

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).

Comment 3 Brandon 2023-05-30 13:44:26 PDT

This appears to be a duplicate of the issue I am working on.

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

Comment 4 Chris Dumez 2023-05-30 13:49:05 PDT


*** This bug has been marked as a duplicate of bug 255924 ***