Bug 153708 – [GTK] http/tests/cache/disk-cache/disk-cache-last-modified.html is failing

• Status: NEW
• Component: WebKitGTK

[Michael Catanzaro]

http/tests/cache/disk-cache/disk-cache-last-modified.html has been failing since it was added in r188690:

--- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/http/tests/cache/disk-cache/disk-cache-last-modified-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/http/tests/cache/disk-cache/disk-cache-last-modified-actual.txt
@@ -10,30 +10,30 @@
 response source: Disk cache
 
 response headers: {"Last-Modified":"Thu, 01 Jan 1970 00:00:00 GMT"}
-response source: Network
+response source: Disk cache
 
 response headers: {"Last-Modified":"invalid"}
-response source: Network
+response source: Disk cache
 
 --------Testing loads through memory cache (XHR behavior)--------
 response headers: {"Last-Modified":"Thu, 01 Jan 2000 00:00:00 GMT"}
 response source: Memory cache
 
 response headers: {"Last-Modified":"Thu, 01 Jan 1970 00:00:00 GMT"}
-response source: Network
+response source: Memory cache
 
 response headers: {"Last-Modified":"invalid"}
-response source: Network
+response source: Memory cache
 
 --------Testing loads through memory cache (subresource behavior)--------
 response headers: {"Last-Modified":"Thu, 01 Jan 2000 00:00:00 GMT"}
 response source: Memory cache
 
 response headers: {"Last-Modified":"Thu, 01 Jan 1970 00:00:00 GMT"}
-response source: Network
+response source: Memory cache
 
 response headers: {"Last-Modified":"invalid"}
-response source: Network
+response source: Memory cache
 
 PASS successfullyParsed is true

[Carlos Garcia Campos]

I can't reproduce this locally.

[Carlos Garcia Campos]

This test was added to fix a workaround in CFNetwork, so the tests could be skipped in GTK+. However, I'm not so sure it's a CFNetwork bug, but a problem in servers, so we might want to behave the same way Mac port does. There's an interesting discussion about this in bug #148162. The thing is that in case of an invalid date in Last-Modified header, we are getting Epoch as date, and then caching those resources. I agree with the reasoning in bug #148162 and the decision made for the Mac port as well. It's very unlikely that are breaking some site using Epoch on purpose, and I really think we would be fixing more cases than broke, anyway. What do you think?

[Carlos Garcia Campos]

I'm confused now. If I run the test manually launching the server with Tools/Scripts/run-webkit-httpd and using WTR it gives the expected results, but if I use Tools/Scripts/run-webkit-tests the memory cache is still used.

[Michael Catanzaro]

My vote is to do what Apple does, treat epoch as invalid, and bypass both caches. A small minority of sites send these broken headers: do we display them broken for four years, or do we display them slowly? I vote for slowly. If I couldn't decide based on that alone, I would still favor following what Apple does.

But, I think both options are reasonable.

[Vitaly Dyackhov]

Pull request: https://github.com/WebKit/WebKit/pull/6207

[EWS]

Test gardening commit 256440@main (6f536b7be60e): <https://commits.webkit.org/256440@main>

Reviewed commits have been landed. Closing PR #6207 and removing active labels.