Bug 257327 – Old url hash fragment is used when loading page from cache

• Component: Page Loading
• Status: RESOLVED DUPLICATE

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

[Alexey Proskuryakov]

Is this the same as bug 255924?

[Chris Dumez]

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

[Brandon]

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

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

[Chris Dumez]

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