Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
6312008:
Remove revalidation check from PrerenderResourceHandler. (Closed)
|
Created:
9 years, 11 months ago by cbentzel Modified:
9 years, 7 months ago CC:
chromium-reviews, Paweł Hajdan Jr., mmenke Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionRemove revalidation check from PrerenderResourceHandler.
This was initially a way to try to prevent prerendering non-idempotent GETs. A large number of pages were unable to prerender effectively this way due to short max-age's or other cache directives.
BUG=None
TEST=unit_tests --gtest_filter="*PrerenderResourceHandler*"
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=72130
Patch Set 1 #
Messages
Total messages: 9 (0 generated)
This removes the cache revalidation checks. cc'ed Darin, who initially asked for something similar to detect non-idempotent GETs. A large number of sites are unable to prerender due to very short expiry on the top-level resource. Sites can always detect Purpose: headers and change behavior in that case.
Doesn't this get you back to the original problem? How do you know that you can show a pre-rendered page when it may correspond to an old version of that page? Maybe cookies have since changed or maybe something else has changed that would invalidate showing the old page? (For example, the user could have signed out.)
Regarding cookies: One avenue we are considering is having a new CookieStore for each prerendered page based on the current profile's CookieStore [and a new ChromeURLRequestContext to match], which is in memory only. Cookie mutations made in the prerendered page are only done in the prerendered's store. If the prerendered page is pruned prior to being used, all changes will be easily discarded. If the user decides to see the page, we compare diffs on the original cookie store with the prerendered cookie store, and cancel the prerendered page in that case. Otherwise, diffs are committed to the main store, and ultimately persist out to the SQLlite db. I've been talking to rdsmith about different ways to implement this. Let me know if you'd like more details. On Thu, Jan 20, 2011 at 12:18 PM, <darin@chromium.org> wrote: > Doesn't this get you back to the original problem? How do you know that > you can > show a pre-rendered page when it may correspond to an old version of that > page? > Maybe cookies have since changed or maybe something else has changed that > would > invalidate showing the old page? (For example, the user could have signed > out.) > > > http://codereview.chromium.org/6312008/ >
That sounds reasonable to me. Note that there will be complications with the "blocked cookie" UI. Note also that things are getting more complicated now. "Cookies" is growing to include other forms of client-side storage. The rendered page may depend on the rows in a WebSQL database or it may depend on the contents of a file in the filesystem. Aren't there potential race conditions with those as well? It seems like there are a lot of subtle ways that prerendering can fail, assuming that JavaScript is allowed to run. -Darin On Thu, Jan 20, 2011 at 9:56 AM, Chris Bentzel <cbentzel@chromium.org>wrote: > Regarding cookies: > > One avenue we are considering is having a new CookieStore for each > prerendered page based on the current profile's CookieStore [and a new > ChromeURLRequestContext to match], which is in memory only. Cookie mutations > made in the prerendered page are only done in the prerendered's store. If > the prerendered page is pruned prior to being used, all changes will be > easily discarded. If the user decides to see the page, we compare diffs on > the original cookie store with the prerendered cookie store, and cancel the > prerendered page in that case. Otherwise, diffs are committed to the main > store, and ultimately persist out to the SQLlite db. > > I've been talking to rdsmith about different ways to implement this. Let me > know if you'd like more details. > > On Thu, Jan 20, 2011 at 12:18 PM, <darin@chromium.org> wrote: > >> Doesn't this get you back to the original problem? How do you know that >> you can >> show a pre-rendered page when it may correspond to an old version of that >> page? >> Maybe cookies have since changed or maybe something else has changed that >> would >> invalidate showing the old page? (For example, the user could have signed >> out.) >> >> >> http://codereview.chromium.org/6312008/ >> > >
Actually, even if JavaScript is not executed, in the near future, HTML on the page will be able to reference files in the local filesystem. <img src="filesystem:http://www.google.com/persistent/foo/bar.gif"> That'll look in the persistent filesystem for http://www.google.com/ for a file at /foo/bar.gif. Suppose after prerendering but before showing the page, someone goes and modifies the contents of bar.gif? (Maybe bar.gif would have meanwhile been modified.) I know this is all quite hypothetical, but I think it is worth considering such a future. -Darin On Thu, Jan 20, 2011 at 10:04 AM, Darin Fisher <darin@chromium.org> wrote: > That sounds reasonable to me. Note that there will be complications with > the "blocked cookie" UI. > > Note also that things are getting more complicated now. "Cookies" is > growing to include other forms of client-side storage. The rendered page > may depend on the rows in a WebSQL database or it may depend on the contents > of a file in the filesystem. Aren't there potential race conditions with > those as well? > > It seems like there are a lot of subtle ways that prerendering can fail, > assuming that JavaScript is allowed to run. > > -Darin > > > On Thu, Jan 20, 2011 at 9:56 AM, Chris Bentzel <cbentzel@chromium.org>wrote: > >> Regarding cookies: >> >> One avenue we are considering is having a new CookieStore for each >> prerendered page based on the current profile's CookieStore [and a new >> ChromeURLRequestContext to match], which is in memory only. Cookie mutations >> made in the prerendered page are only done in the prerendered's store. If >> the prerendered page is pruned prior to being used, all changes will be >> easily discarded. If the user decides to see the page, we compare diffs on >> the original cookie store with the prerendered cookie store, and cancel the >> prerendered page in that case. Otherwise, diffs are committed to the main >> store, and ultimately persist out to the SQLlite db. >> >> I've been talking to rdsmith about different ways to implement this. Let >> me know if you'd like more details. >> >> On Thu, Jan 20, 2011 at 12:18 PM, <darin@chromium.org> wrote: >> >>> Doesn't this get you back to the original problem? How do you know that >>> you can >>> show a pre-rendered page when it may correspond to an old version of that >>> page? >>> Maybe cookies have since changed or maybe something else has changed that >>> would >>> invalidate showing the old page? (For example, the user could have >>> signed out.) >>> >>> >>> http://codereview.chromium.org/6312008/ >>> >> >> >
Do you have a pointer to documentation for the filesystem URL scheme? Web search for "filesystem scheme URL" did not turn up anything. I'm guessing it's an extension of http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ On Thu, Jan 20, 2011 at 1:25 PM, Darin Fisher <darin@chromium.org> wrote: > Actually, even if JavaScript is not executed, in the near future, HTML on > the page will be able to reference files in the local filesystem. > > <img src="filesystem:http://www.google.com/persistent/foo/bar.gif"> > > That'll look in the persistent filesystem for http://www.google.com/ for a > file at /foo/bar.gif. Suppose after prerendering but before showing the > page, someone goes and modifies the contents of bar.gif? (Maybe bar.gif > would have meanwhile been modified.) > > I know this is all quite hypothetical, but I think it is worth considering > such a future. > > -Darin > > > > On Thu, Jan 20, 2011 at 10:04 AM, Darin Fisher <darin@chromium.org> wrote: > >> That sounds reasonable to me. Note that there will be complications with >> the "blocked cookie" UI. >> >> Note also that things are getting more complicated now. "Cookies" is >> growing to include other forms of client-side storage. The rendered page >> may depend on the rows in a WebSQL database or it may depend on the contents >> of a file in the filesystem. Aren't there potential race conditions with >> those as well? >> >> It seems like there are a lot of subtle ways that prerendering can fail, >> assuming that JavaScript is allowed to run. >> >> -Darin >> >> >> On Thu, Jan 20, 2011 at 9:56 AM, Chris Bentzel <cbentzel@chromium.org>wrote: >> >>> Regarding cookies: >>> >>> One avenue we are considering is having a new CookieStore for each >>> prerendered page based on the current profile's CookieStore [and a new >>> ChromeURLRequestContext to match], which is in memory only. Cookie mutations >>> made in the prerendered page are only done in the prerendered's store. If >>> the prerendered page is pruned prior to being used, all changes will be >>> easily discarded. If the user decides to see the page, we compare diffs on >>> the original cookie store with the prerendered cookie store, and cancel the >>> prerendered page in that case. Otherwise, diffs are committed to the main >>> store, and ultimately persist out to the SQLlite db. >>> >>> I've been talking to rdsmith about different ways to implement this. Let >>> me know if you'd like more details. >>> >>> On Thu, Jan 20, 2011 at 12:18 PM, <darin@chromium.org> wrote: >>> >>>> Doesn't this get you back to the original problem? How do you know that >>>> you can >>>> show a pre-rendered page when it may correspond to an old version of >>>> that page? >>>> Maybe cookies have since changed or maybe something else has changed >>>> that would >>>> invalidate showing the old page? (For example, the user could have >>>> signed out.) >>>> >>>> >>>> http://codereview.chromium.org/6312008/ >>>> >>> >>> >> >
On Thu, Jan 20, 2011 at 1:04 PM, Darin Fisher <darin@chromium.org> wrote: > That sounds reasonable to me. Note that there will be complications with > the "blocked cookie" UI. > > Thanks, I hadn't considered that. > Note also that things are getting more complicated now. "Cookies" is > growing to include other forms of client-side storage. The rendered page > may depend on the rows in a WebSQL database or it may depend on the contents > of a file in the filesystem. Aren't there potential race conditions with > those as well? > Yes. There are increasing number of local storage [DOM local storage, indexeddb, etc.], and we don't have good answers for all of them.
It is presently something that Eric is working on adding to the spec. -Darin On Thu, Jan 20, 2011 at 11:20 AM, Chris Bentzel <cbentzel@chromium.org>wrote: > Do you have a pointer to documentation for the filesystem URL scheme? Web > search for "filesystem scheme URL" did not turn up anything. I'm guessing > it's an extension of > http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ > > > On Thu, Jan 20, 2011 at 1:25 PM, Darin Fisher <darin@chromium.org> wrote: > >> Actually, even if JavaScript is not executed, in the near future, HTML on >> the page will be able to reference files in the local filesystem. >> >> <img src="filesystem:http://www.google.com/persistent/foo/bar.gif"> >> >> That'll look in the persistent filesystem for http://www.google.com/ for >> a file at /foo/bar.gif. Suppose after prerendering but before showing the >> page, someone goes and modifies the contents of bar.gif? (Maybe bar.gif >> would have meanwhile been modified.) >> >> I know this is all quite hypothetical, but I think it is worth considering >> such a future. >> >> -Darin >> >> >> >> On Thu, Jan 20, 2011 at 10:04 AM, Darin Fisher <darin@chromium.org>wrote: >> >>> That sounds reasonable to me. Note that there will be complications with >>> the "blocked cookie" UI. >>> >>> Note also that things are getting more complicated now. "Cookies" is >>> growing to include other forms of client-side storage. The rendered page >>> may depend on the rows in a WebSQL database or it may depend on the contents >>> of a file in the filesystem. Aren't there potential race conditions with >>> those as well? >>> >>> It seems like there are a lot of subtle ways that prerendering can fail, >>> assuming that JavaScript is allowed to run. >>> >>> -Darin >>> >>> >>> On Thu, Jan 20, 2011 at 9:56 AM, Chris Bentzel <cbentzel@chromium.org>wrote: >>> >>>> Regarding cookies: >>>> >>>> One avenue we are considering is having a new CookieStore for each >>>> prerendered page based on the current profile's CookieStore [and a new >>>> ChromeURLRequestContext to match], which is in memory only. Cookie mutations >>>> made in the prerendered page are only done in the prerendered's store. If >>>> the prerendered page is pruned prior to being used, all changes will be >>>> easily discarded. If the user decides to see the page, we compare diffs on >>>> the original cookie store with the prerendered cookie store, and cancel the >>>> prerendered page in that case. Otherwise, diffs are committed to the main >>>> store, and ultimately persist out to the SQLlite db. >>>> >>>> I've been talking to rdsmith about different ways to implement this. Let >>>> me know if you'd like more details. >>>> >>>> On Thu, Jan 20, 2011 at 12:18 PM, <darin@chromium.org> wrote: >>>> >>>>> Doesn't this get you back to the original problem? How do you know >>>>> that you can >>>>> show a pre-rendered page when it may correspond to an old version of >>>>> that page? >>>>> Maybe cookies have since changed or maybe something else has changed >>>>> that would >>>>> invalidate showing the old page? (For example, the user could have >>>>> signed out.) >>>>> >>>>> >>>>> http://codereview.chromium.org/6312008/ >>>>> >>>> >>>> >>> >> >
LGTM |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
