[Webkit-unassigned] [Bug 152424] Cache redirects as separate entries

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 18 10:47:13 PST 2015


https://bugs.webkit.org/show_bug.cgi?id=152424

--- Comment #4 from Antti Koivisto <koivisto at iki.fi> ---
(In reply to comment #3)
> Did you change all uses of NetworkCache::singleton().isEnabled to
> canUseCache?  This seems like a very important change that we should've done
> long ago.

Yeah, everywhere in NetworkResourceLoader.

> Why don't we need to remove any cache entries here any more?

I don't think so. That case was there for expired redirect chains. Now redirects expire like other cache entries.

> This is only called from one place and might not need its own function
> unless you plan to use it from other places in the future.

It looked nicer like this in the call site.

> > LayoutTests/http/tests/cache/disk-cache/disk-cache-redirect-expected.txt:10
> > +response source: Disk cache
> 
> How is the first response from the Disk cache?

301 Permanent Redirect is cacheable by default unless other headers say otherwise. 302, 303 and 303 are not cached by default.
> 
> > LayoutTests/http/tests/cache/disk-cache/disk-cache-redirect.html:17
> > +  { responseHeaders: {'Cache-control': 'max-age=0' } },
> > +  { responseHeaders: {'Cache-control': 'max-age=100' } },
> 
> If I'm correct, the first cache entry expires immediately, and the second
> cache entry does not expire immediately, so we test making a request for a
> cache entry that has expired.  Why don't we make another request after the
> second one to test making a request for a cache entry that has not expired?

Thase are independent test cases (or actually used to generate individual test cases by generating all header permutations). Each test is loaded multiple times to see if it gets faced. You see the actual cases in the test output (the first warmup load doesn't generate output).

Thanks for review.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151218/795c0678/attachment.html>


More information about the webkit-unassigned mailing list