[whatwg] Application Cache for on-line sites
felix.halim at gmail.com
Sun Feb 13 19:52:21 PST 2011
I have a use case where it is preferable that the main page is not cached:
Suppose you have a main page that changes based on it's ID:
The appCache will store each main page with different id in separate
cache, which is undesirable!
And we DON'T want to cache the main pages, since the content differs
significantly (think of it as a forum website).
Of course, you can make the page.php as an "application" entirely,
then the id + its content are loaded via AJAX, but that violates the
nature of URL linking! Other websites cannot easily link to the
"application" with page id = 10 (since you remove the "?id=10" from
the URL). Of course you can use "SHE BANG" into the URL (to specify
the id) to bookmark (or to link to) AJAX pages, but that means
That is why, we have to have a mechanisms to exclude the main page to be cached.
The main goal here is NOT to make the page offline, but to cache the
resources that the page uses (i.e, .js, .css, images, etc...) that are
very likely to be IMMUTABLE (particularly the jQuery.js and jQueryUI
css+images that almost every sites uses!). It should degrade
gracefully for older browsers if they don't understand the manifest
On Sat, Feb 12, 2011 at 7:03 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> bcc chromium-html5
> In addition to what Michael has cited, I've had many developers (at various
> Google events) ask why we don't have some API like this as well. I think
> it's clear there's demand.
> On Fri, Feb 11, 2011 at 1:14 PM, Michael Nordman <michaeln at google.com>wrote:
>> 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.
>> hixie said...
>> > 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
>> 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>
>> > This type of request (see forwarded message below) to utilize the
>> > application cache for subresource loads into documents that are not
>> > in the cache has come up several times now. The current feature set is
>> > focused on the "offline" use case. Is it worth making additions such that
>> > document that loads from a server can utilize the resources in an
>> > 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
>> > the appcache (so subresources loads hit the cache) but not add the
>> > 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.
>> > From
>> > http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
>> > :
>> > "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
>> > powerful.
>> > --
>> > 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
>> > http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
More information about the whatwg