[whatwg] Application Cache for on-line sites
michaeln at google.com
Fri Feb 11 13:14:49 PST 2011
Waking this feature request up again as it's been requested multiple
times, I think the ability to utilize an appcache w/o having to have
the page added to it is the #1 appcache feature request that I've
* The Gmail mobile team has mentioned this.
* Here's a thread on a chromium.org mailing list where this feature is
requested: "How to instruct the main page to be not cached?"
* More recently this has been requested in the context of an
application that uses pushState to alter the url of the main page.
To keep this discussion distinct from others, I'm pulling in the few
comments that have been made on another thread.
> Why can't the pages just switch to a more AJAX-like model rather than
> having the main page still load over the network? The main page loading
> over the network is a big part of the page being slow.
and i replied...
> The premise of the feature request is that the "main" pages aren't
> cached at all.
> | I tried to use the HTML5 Application Cache to improve the performances
> | of on-line sites (all the tutorials on the web write only about usage
> | with off-line apps)
> As for "why can't the pages just switch", I can't speak for andrea,
> but i can guess that a redesign of that nature was out of scope and/or
> would conflict with other requirements around how the url address
> space of the app is defined.
Once you get past the "should this be a feature" question, there are
some questions to answer.
1) How does an author indicate which pages should be added to the
cache and which should not?
A few ideas...
a. <html useManifest='x'>
b. If the main resource has a "no-store" header, don't add it to the
cache, but do associate the document with the cache.
b. A new manifest section to define a prefix matched namespace for these pages.
2) What sequence of events does a page that just uses the cache w/o
being added to it observe?
3) At what point do subresources in an existing appcache start getting
utlized by such pages? What if the appcache is stale? Do subresource
loads cause revalidation?
On Mon, Dec 20, 2010 at 12:56 PM, Michael Nordman <michaeln at chromium.org> wrote:
> This type of request (see forwarded message below) to utilize the
> application cache for subresource loads into documents that are not stored
> in the cache has come up several times now. The current feature set is very
> focused on the "offline" use case. Is it worth making additions such that a
> document that loads from a server can utilize the resources in an appcache?
> Today we have <html manifest="manifestFile">, which adds the document
> containing this tag to the appcache and associates that doc with that
> appcache such that subresource loads hit the appcache.
> Not a complete proposal, but...
> What if we had something along the lines of <html
> useManifest=''manifestFile">, which would do the association of the doc with
> the appcache (so subresources loads hit the cache) but not add the document
> to the cache?
> ---------- Forwarded message ----------
> From: UVL <andrea.doimo at gmail.com>
> Date: Sun, Dec 19, 2010 at 1:35 PM
> Subject: [chromium-html5] Application Cache for on-line sites
> To: Chromium HTML5 <chromium-html5 at chromium.org>
> I tried to use the HTML5 Application Cache to improve the performances
> of on-line sites (all the tutorials on the web write only about usage
> with off-line apps)
> I created the manifest listing all the js, css and images, and the
> performances were really exciting, until I found that even the page
> HTML was cached, despite it was not listed in the manifest. The pages
> of the site are in PHP, so I don't want them to be cached.
> "Authors are encouraged to include the main page in the manifest also,
> but in practice the page that referenced the manifest is automatically
> cached even if it isn't explicitly mentioned."
> Is there a way to have this automating caching disabled?
> Note: I know that caching can be controlled via HTTP headers, but I
> just wanted to try this way as it looks quite reliable, clean and
> You received this message because you are subscribed to the Google Groups
> "Chromium HTML5" group.
> To post to this group, send email to chromium-html5 at chromium.org.
> To unsubscribe from this group, send email to
> chromium-html5+unsubscribe at chromium.org.
> For more options, visit this group at
More information about the whatwg