Bug 70209 – Hard Refresh Bug. Before a new document loader is created for reload, the cache policy of initial request should set to ReloadIgnoringCacheData.

• Status: UNCONFIRMED
• Component: Page Loading

[Sungman Kim]

Hard refresh (No cache data use) is not working at first try, but working correctly after second try.
This is because the cache policy is copied from the previous document loader's policy, which is UseProtocalCachePolicy.
Even though the cache policy is set to ReloadIgnoringCacheData after document loader creation by setCachePolicy() on FrameLoader::reload(), the cache policy of m_originalRequest is still UseProtocolCachePolicy.
The cache policy of Subresource's request is set to 'documentLoader()->originalRequest().cachePolicy()' on FrameLoader::addExtraFieldsToRequest() function.
So it would be UseProtocolCachePolicy at first try, then the HTTPHeaderFields of "Cache-Control : no-cache" and "Pragma : no-cache" could not be added to 
the Subresource's request. The Cache policy of Subresource's request must be ReloadIgnoringCacheData to be set with no-cache header fields.
This bug is caused by wrong position where the cache policy is set to ReloadIgnoringCacheData, we fixed it.

[Sungman Kim]

Created attachment 111195 [details]
Hard refresh bug patch. Fixed the cache policy of initial request.

[Alexey Proskuryakov]

CC'ing Antti, who implemented hard refresh.

Please update the patch to trunk, so that it suvvessfully applies, and EWS bots can try it.

[Sungman Kim]

Created attachment 111410 [details]
Hard refresh bug patch. Fixed the cache policy of initial request.

[Sungman Kim]

I attached updated patch again.

[Antti Koivisto]

Comment on attachment 111410 [details]
Hard refresh bug patch. Fixed the cache policy of initial request.

This needs a test case. Ideally it would an automatic test (DRT supports reloads though will probably need to be extended to support forced origin reloads). A manual test of some sort would be better than nothing too.

r- for the lack of any way to verify the change.

[Sungman Kim]

(In reply to comment #5)
> (From update of attachment 111410 [details])
> This needs a test case. Ideally it would an automatic test (DRT supports reloads though will probably need to be extended to support forced origin reloads). A manual test of some sort would be better than nothing too.
> r- for the lack of any way to verify the change.

1. Connect to "www.refreshyourcache.com/en/cache-test"
2. You can find THE RED IMAGE on page.
3. Refresh (Reload) the page adn see what happens.
   If the hard refresh works well and your cache is cleared successfully then THE RED IMAGE will be changed to THE GREEN IMAGE.
4. But if the hard refresh doesn't work, THE RED IMAGE will be still loaded from your cache.

This is a test case for hard refresh test. I'm sorry but I don't have idea about automatic test.
Please check above test case and give me comments.

[Antti Koivisto]

What is the bug exactly? I tried that page in Safari with TOT WebKit. Doing hard refresh (pressing shift while hitting reload button) turns the image green, apparently the expected result.

As for the automatic tests, if you look under LayoutTests/http/tests/navigation/ you can find several that test reloading.

[Sungman Kim]

(In reply to comment #7)
> What is the bug exactly? I tried that page in Safari with TOT WebKit. Doing hard refresh (pressing shift while hitting reload button) turns the image green, apparently the expected result.
> As for the automatic tests, if you look under LayoutTests/http/tests/navigation/ you can find several that test reloading.

This bug is occurred just at first reload. The red image will be changed to green at second reload. 
Could you please check the first reload works correctly? 
I also tested with Safari with latest WebKit on iPhone, but red image still be displayed at first reload.

[Sungman Kim]

Please review this issue. As I commented, this hard refresh bug is occured only at the first try.