Do not initiate revalidation of Resource with redirects from MemoryCache

third_party/WebKit/Source/core/fetch/Resource.cpp

Index: third_party/WebKit/Source/core/fetch/Resource.cpp
diff --git a/third_party/WebKit/Source/core/fetch/Resource.cpp b/third_party/WebKit/Source/core/fetch/Resource.cpp
index 029779ee39d9a60a977f94adfd23063322fce7b8..7c9fecd44faf24e3df92821ae909fe64b0cbae24 100644
--- a/third_party/WebKit/Source/core/fetch/Resource.cpp
+++ b/third_party/WebKit/Source/core/fetch/Resource.cpp
@@ -960,6 +960,11 @@ bool Resource::canUseCacheValidator()
 
     if (hasCacheControlNoStoreHeader())
         return false;
+
+    // Do not revalidate Resource with redirects. https://crbug.com/613971
+    if (!redirectChain().isEmpty())

[Nate Chapin, 2016/05/27 17:00:57]

How does this interact with canReuseRedirectChain()?

[hiroshige, 2016/05/30 06:28:50]

This CL prohibits |Revalidate| for Resource with redirects, but not |Use| for
such a Resource.
Therefore, canReuseRedirectChain() still can return true for Resource with
redirects (meaning "we can |Use|"), while canUseCacheValidator() always returns
false (meaning "we cannot |Revalidate|").
In such case,
- We can |Use| the Resource without revalidating (when other conditions met).
- We can NOT |Revalidate| the Resource, because of Chromium/Blink's
implementation.
- We can |Reload| the Resource.

+        return false;
+
     return m_response.hasCacheValidatorFields() || m_resourceRequest.hasCacheValidatorFields();
 }