Synchronous requests that get a 304 clobber the cached response body.

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

Index: third_party/WebKit/Source/core/fetch/ResourceLoader.cpp
diff --git a/third_party/WebKit/Source/core/fetch/ResourceLoader.cpp b/third_party/WebKit/Source/core/fetch/ResourceLoader.cpp
index 0c6b3611c2b427cdc9156678b8d948ea885aeda8..5f6a736408aa2a698f9886dc7dee67c3fe36c82d 100644
--- a/third_party/WebKit/Source/core/fetch/ResourceLoader.cpp
+++ b/third_party/WebKit/Source/core/fetch/ResourceLoader.cpp
@@ -516,7 +516,8 @@ void ResourceLoader::requestSynchronously()
     RefPtr<ResourceLoadInfo> resourceLoadInfo = responseOut.toResourceResponse().resourceLoadInfo();
     int64_t encodedDataLength = resourceLoadInfo ? resourceLoadInfo->encodedDataLength : WebURLLoaderClient::kUnknownEncodedDataLength;
     m_fetcher->didReceiveData(m_resource, dataOut.data(), dataOut.size(), encodedDataLength);
-    m_resource->setResourceBuffer(dataOut);
+    if (dataOut.size())

[Yoav Weiss, 2015/12/31 06:29:17]

Isn't there a scenario where the response *has* changed to be a zero sized
response and should be clobbered? Wouldn't it be better the special case 304s?

[Nate Chapin, 2016/01/04 22:15:54]

In all non-revalidation cases, Resource::m_data will be empty at this point. If
a revalidation attempt returns something other than a 304,
Resource::revalidationFailed() will clear the buffer automatically, so calling
setResourceBuffer() again with an empty buffer will be a noop.

However, I just noticed that I accidnetally left the m_fetcher->didReceiveData()
call outside of the if(), which seems wrong for the 304 case. Updated that.

[Yoav Weiss, 2016/01/05 14:13:03]

What's the relationship between Resource::m_data and dataOut?
so `dataOut.size()` is non-zero in all cases other than 304?
Could you add a comment making that explicit?

+        m_resource->setResourceBuffer(dataOut);
     didFinishLoading(0, monotonicallyIncreasingTime(), encodedDataLength);
 }