Changeset 188953 in webkit

Timestamp:

Aug 26, 2015 12:49:53 AM (9 years ago)

Author:

Carlos Garcia Campos

Message:

Merge r188755 - Regression(r188698): http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header.html is very flaky
​https://bugs.webkit.org/show_bug.cgi?id=148205

Reviewed by Antti Koivisto.

Source/WebKit2:

After r188640, successful revalidation of resources in the memory cache
would cause us to drop the corresponding resource in the disk cache.
This patch addresses the issue by not removing the cache entry if the
response is a successful revalidation (i.e. status code == 304).

Longer term, we should probably update the entry in the disk cache (if
it exists) when it is revalidated by the memory cache. Currently,
revalidation by the memory cache bypasses the disk cache and goes
straight to the network. Then, when the response comes back as a 304,
we try and store the response in the cache. However, a 304 status code
is not cacheable so the cache rejects it.

• NetworkProcess/cache/NetworkCache.cpp:

(WebKit::NetworkCache::Cache::store):

LayoutTests:

• http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header.html:

Drop temporary fix landed in r188698 to make the test less flaky.

Location:

releases/WebKitGTK/webkit-2.10

Files:

• LayoutTests/ChangeLog (modified) (1 diff)
• Source/WebKit2/ChangeLog (modified) (1 diff)
• Source/WebKit2/NetworkProcess/cache/NetworkCache.cpp (modified) (1 diff)

releases/WebKitGTK/webkit-2.10/LayoutTests/ChangeLog

@@ +1 @@
+2015-08-21  Chris Dumez  <cdumez@apple.com>
+
+        Regression(r188698): http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header.html is very flaky
+        https://bugs.webkit.org/show_bug.cgi?id=148205
+
+        Reviewed by Antti Koivisto.
+
+        * http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header.html:
+        Drop temporary fix landed in r188698 to make the test less flaky.
+
+2015-08-20  Chris Dumez  <cdumez@apple.com>
+
+        REGRESSION: http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header.html is very flaky
+        https://bugs.webkit.org/show_bug.cgi?id=148205
+
+        Unreviewed, give the disk cache a chance to settle down before querying
+        the resource again. This fixes the flakiness locally. Longer term, I will
+        try and figure out why the cache is sometimes revalidating if the resource
+        is requested very quickly after.
+
+        * http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header.html:
+
 2015-08-19  Chris Dumez  <cdumez@apple.com>
 

releases/WebKitGTK/webkit-2.10/Source/WebKit2/ChangeLog

@@ +1 @@
+2015-08-21  Chris Dumez  <cdumez@apple.com>
+
+        Regression(r188698): http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header.html is very flaky
+        https://bugs.webkit.org/show_bug.cgi?id=148205
+
+        Reviewed by Antti Koivisto.
+
+        After r188640, successful revalidation of resources in the memory cache
+        would cause us to drop the corresponding resource in the disk cache.
+        This patch addresses the issue by not removing the cache entry if the
+        response is a successful revalidation (i.e. status code == 304).
+
+        Longer term, we should probably update the entry in the disk cache (if
+        it exists) when it is revalidated by the memory cache. Currently,
+        revalidation by the memory cache bypasses the disk cache and goes
+        straight to the network. Then, when the response comes back as a 304,
+        we try and store the response in the cache. However, a 304 status code
+        is not cacheable so the cache rejects it.
+
+        * NetworkProcess/cache/NetworkCache.cpp:
+        (WebKit::NetworkCache::Cache::store):
+
 2015-08-19  Chris Dumez  <cdumez@apple.com>
 

releases/WebKitGTK/webkit-2.10/Source/WebKit2/NetworkProcess/cache/NetworkCache.cpp

@@ -408 +408 @@
         auto key = makeCacheKey(originalRequest);
 
-        // Make sure we don't keep a stale entry in the cache.
-        remove(key);
+        auto isSuccessfulRevalidation = response.httpStatusCode() == 304;
+        if (!isSuccessfulRevalidation) {
+            // Make sure we don't keep a stale entry in the cache.
+            remove(key);
+        }
 
         if (m_statistics)