[Webkit-unassigned] [Bug 30862] Dynamically inserted subresources aren't revalidated even when the containing document is reloaded

Sat Aug 7 10:46:41 PDT 2010

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

Kyle Simpson <getify at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |getify at gmail.com

--- Comment #12 from Kyle Simpson <getify at gmail.com>  2010-08-07 10:46:41 PST ---
Alexey-
As noted in #32423 (which I filed), *that* bug is the opposite of this one. 32423 is about the cache not being used in a circumstance where it *should* be used. This bug is about the cache being used in a case where it *shouldn't* be.

As for this bug as well as #35883 (which I filed), I think part of the confusion is that of how and when a resource is "marked" as needing to be reloaded on the next page-refresh.

If the resource *starts* loading before onload occurs, but finishes loading *after* the page-onload fires, is it marked as needing re-validation for next shift+refresh? If the resource starts *and* completes loading *before* the page-onload, is it marked? If the resource is requested *after* page-onload and completes some time later, is it marked?

If a resource is marked as needing re-validation based on when it is loaded or completes loading, it leads to these race conditions.

But if instead a resource is not marked *until the time of reload* (meaning all currently loaded resources in a page are marked when you hit refresh), then it shouldn't matter how those resources got to the page originally, right?

If some get there through normal static load, and some get there on-demand/dynamically later, in all cases, don't you *always* want to revalidate all current page resources when the page is refreshed?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.