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
I can't reproduce this locally.
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?
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.
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.
Pull request: https://github.com/WebKit/WebKit/pull/6207
Test gardening commit 256440@main (6f536b7be60e): <https://commits.webkit.org/256440@main> Reviewed commits have been landed. Closing PR #6207 and removing active labels.