Cached "Expires" header is not updated upon successful resource revalidation. This affects both our disk cache and our memory cache. This is because we shouldUpdateHeaderAfterRevalidation() in CacheValidation.cpp returns false for the "Expires" header. HTTP servers such as Apache returns an "Expires" header in their 304 responses and the "Expires" header is potentially a new one. However, our caches ignore it and keep the old one, which means that the cached resource expires sooner than it should. See the following Apache bugs that explain the issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=24884 https://bz.apache.org/bugzilla/show_bug.cgi?id=25123 There is a comment in the code that says the list of headers matches Chromium's net library but that's not the case, at least not anymore: http://osxr.org/android/source/external/chromium/net/http/http_response_headers.cc
<rdar://problem/20348059>
Good catch
Created attachment 249761 [details] Patch
Comment on attachment 249761 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=249761&action=review r=me, nice. We should also add some explicit Expires header tests at some point. > LayoutTests/http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header-expected.txt:7 > +response headers: {"Expires":"now(0)","ETag":"match"} Would be nice if this printed the expiresInFutureIn304 flag too. The suggestion below would cover that automatically. > LayoutTests/http/tests/cache/disk-cache/disk-cache-revalidation-new-expire-header.html:8 > + { responseHeaders: {'Expires': 'now(0)', 'ETag': 'match' }, expiresInFutureIn304: true }, Another option would be to add another magical Expires value (nowButUpdateToFuture or something). Don't know if that is really any better.
Created attachment 249773 [details] Patch
Comment on attachment 249773 [details] Patch Clearing flags on attachment: 249773 Committed r182157: <http://trac.webkit.org/changeset/182157>
All reviewed patches have been landed. Closing bug.