Don't attempt to revalidate a Resource with a 304 response.

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

Index: third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
diff --git a/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp b/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
index 07532df95eb5102f6ac718cb61b68d87d8022689..7e9940e0f7079c3d4a0e23bb69e4adb54769528f 100644
--- a/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
+++ b/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
@@ -709,9 +709,17 @@ ResourceFetcher::RevalidationPolicy ResourceFetcher::determineRevalidationPolicy
         return Reload;
 
     // Certain requests (e.g., XHRs) might have manually set headers that require revalidation.
-    // FIXME: In theory, this should be a Revalidate case. In practice, the MemoryCache revalidation path assumes a whole bunch
+    // In theory, this should be a Revalidate case. In practice, the MemoryCache revalidation path assumes a whole bunch
     // of things about how revalidation works that manual headers violate, so punt to Reload instead.
-    if (request.isConditional())
+    //
+    // Similarly, a request with manually added revalidation headers can lead
+    // to a 304 response for a request that wasn't flagged as a revalidation
+    // attempt. Normally, successful revalidation will maintain the original
+    // response's status code, but for a manual revalidation the response code
+    // remains 304. In this case, the Resource likely has insufficient context
+    // to provide a useful cache hit or revalidation.
+    // See http://crbug.com/643659
+    if (request.isConditional() || existingResource->response().httpStatusCode() == 304)
         return Reload;
 
     // Don't try to reuse an in-progress async request for a new sync request.