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

[bugzilla-daemon at webkit.org]

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





--- Comment #61 from Kyle Simpson <getify at gmail.com>  2011-09-21 12:17:22 PST ---
(In reply to comment #60)
> Fundamentally, I think the issue is that web applications want to have it both ways: apply revalidation to some set of requests (the source of the app) but not to another set of requests (the data the app operates on). 

Actually, I think the implementation detail that's really the culprit comes from an email exchange with Boris:

> Your proposed solution assumes the existence of a "list of resources the 
page has loaded", which simply doesn't exist....

So, if I understand correctly, is the fear that a page would have requested via XHR a bunch of data (JSON, XML), and that those Ajax data requests don't make sense (and are quite wasteful) to re-request?

If I'm correct (finally) in understanding this situation, the problem is actually that the *browser* (has nothing to do with the user or app) can't distinguish between bytes loaded for resources, and bytes loaded for transient data.

Let's explore if there's any way that the browser can in fact make a better distinction.

At first glance, it seems that XHR loading is the approriate trigger. XHR is for data, everything else is data.

But, there's (at least) two outliers that muddy the waters: data loaded as JSON-P, and resources loaded as XHR (like loading a script via XHR and then eval()'ing it or injecting it).

For the case of XHR that is loading a resource (in other words, *this* XHR should get flagged for re-validation), could we have the author set a request-header like "X-Revalidatable-Resource: true" to tell the browser that this request/response is a resource and should be treated as such as far as caching, revalidation, etc?

For the case of data loaded via a script-tag (JSON-P), which is almost always done via dynamically created script elements, could the author set a flag on the resource to un-flag it from revalidation... perhaps with a property like `revalidatable` which is always defaulted to `true`, but if set to `false`, then the browser will treat it instead as transient data and not re-validate it?

I realize in both cases, we're proposing new signals that the author has to do, and if they don't do it, we'll have false-positives and false-negatives, respectively. But the upside is, we're putting the onus on the developer to do the signaling, so that the browser doesn't have to use heuristics (which are also probably flawed) or timers (which are certainly flawed).

Is there any hope for an approach similar to this?

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