How to instruct the main page to be not cached?

Felix Halim

unread,

Sep 27, 2010, 11:03:53 PM9/27/10

to chromiu...@chromium.org

Hi,

I have a page that contains many scripts, css, images.
I want to cache them all EXCEPT the main page.
Because the main page changes quite often but the scripts,css,images are not.

The easiest way that should work is to use cache manifest for offline web.
However, if I use cache manifest, the main page will be cached.
And I will have to refresh *twice* to get the latest update on the main page.
I tried inserting the filename under NETWORK section in the cache
manifest, but it doesn't work (it still cache the main page).

I can have all the scripts, css, images stored in localStorage, but
it's a hack...
And it will cause double parsing for the browser...

Is there a work around for this?

Thanks,

Felix Halim

Eric Bidelman

unread,

Sep 28, 2010, 5:29:23 PM9/28/10

to Felix Halim, chromiu...@chromium.org

What is particular is changing on the main page? If it's dynamically driven, that should be ok.

The main page is implicitly cached the app cache. As far as I know, you cannot omit it.

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
To post to this group, send email to chromiu...@chromium.org.
To unsubscribe from this group, send email to chromium-html...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.

--
Eric Bidelman
Developer Relations - Google
e.bid...@google.com

Jeremy Orlow

unread,

Sep 28, 2010, 6:47:41 PM9/28/10

to Eric Bidelman, Felix Halim, chromiu...@chromium.org

Yeah. If you omitted it, then how could you use the site offline?

J

Felix Halim

unread,

Sep 28, 2010, 10:34:17 PM9/28/10

to Eric Bidelman, chromiu...@chromium.org

I should have mentioned earlier the reason:

First, I have a web page that is already linked by many other sites like this:

http://blabla.com/page.php?id=1234

The id parameter changes and different site linked to the page.php
with different id. If I make page.php offline, then terrible thing
happens: each id parameter will get cached in different offline page.

Thus, the page.php has to be redesigned so that it is the only MAIN
page and the id parameter has to come as "hash" based URL like:

http://blabla.com/page.php#1234

So that page.php can be static, offline, cached, and the content of
the page of that id (that can change overtime) can be retrieved
dynamically. But all incoming links from old sites will be broken.
This can be remedied by redirect page.php?id=1234 to page.php#1234,
but I find it dangerous to tickle with url...

In fact, I have experimented with this single page app and I'm not yet
pleased because the UI is lagging 1 second slower: the page has to be
ready first, then you retrieve the data dynamically is 1 second slower
than loading the page + data when the URL is entered.

If only I can cache all but the page.php, all my problems will go away.
I don't need to change/redesign anything on my page, only add a manifest.
That is the simplest thing that works...

Note that: I don't want to make page.php offline.
I just want to use part of HTML5's offline capability to cache things...
And I want to cache all but the main page.

The main reason why I don't want to cache the main page are:
1. the main page changes quite frequently (I don't want to invalidate
all cache that frequent!)
2. it causes double fetch that gives 1 second latency when viewing a
page (first fetch the main page, then fetch the data)
3. if I cache the main page, then any updates on the main page can be
seen by refreshing the main page twice! (because the update is in the
background, and when the update is ready, then you need to refresh
again)
4. I have to REDESIGN the current page to make it behave like a static
app that separates data from application (it's good for long term, but
I don't want to do it now). Otherwise, the single page app will be
cached differently for each id, and guess what? each id that got
cached, have to refresh twice! so the number of refreshes is just too
much.... its far better if the main page is NOT CACHED at all!

So... any suggestion on this?

Felix Halim

Michael Nordman

unread,

Sep 28, 2010, 11:30:26 PM9/28/10

to Felix Halim, Eric Bidelman, chromiu...@chromium.org

Hi Felix,

I hear your frustration. The design center for the application cache really is caching the so called "single page app" completely for offline use. That is a very narrow use case and it sounds like you bust out of those lines on two dimensions: multi-page, not for offline use. So it doesn't surprise me that the feature set is not well formed for your use case.

I'm not sure you can take advantage of the appcache feature set as it current stands for your use case? Some changes to the feature set probably could make it useful for your use case, not that this does you any good right now.

> its far better if the main page is NOT CACHED at all!

That makes sense for what it sounds like you want to accomplish (just cache the static resources and let a live server vend pages, frames, and xhr responses for data). The trouble is the feature set doesn't let you associate a page that is not stored in an appcache with an appcache. What if there was a syntax that allowed you to make that association? Something like...

... where the page would "use" the cache indicated by manifest but not be added to it.

Would that fit your use case?

Felix Halim

unread,

Sep 29, 2010, 12:28:52 AM9/29/10

to Michael Nordman, Eric Bidelman, chromiu...@chromium.org

On Wed, Sep 29, 2010 at 11:29 AM, Michael Nordman <mich...@google.com> wrote:
> I hear your frustration. The design center for the application cache really
> is caching the so called "single page app" completely for offline use. That
> is a very narrow use case and it sounds like you bust out of those lines on
> two dimensions: multi-page, not for offline use. So it doesn't surprise me
> that the feature set is not well formed for your use case.

I think the use case I have wider usage: most (existing) web pages are
not designed as single page app. I don't know the statistics, but I
think things like .js, .css, and images are 99.999% do not change. So
even a "not modified" header will cost unnecessary round-trip cost.
Let say the user press Ctrl+F5 (what they want is to refresh the main
page, and not other things).

In my case I have a page with quite big javascript, css, and images
and I don't want the user to reload everything (even if they press
Ctrl+F5).

> I'm not sure you can take advantage of the appcache feature set as it
> current stands for your use case? Some changes to the feature set probably
> could make it useful for your use case, not that this does you any good
> right now.

One thing in the feature set is that to not cache anything in the
NETWORK section of the manifest file, that means including the main
page (if the main page is listed in the NETWORK section).

>> its far better if the main page is NOT CACHED at all!

> That makes sense for what it sounds like you want to accomplish (just cache
> the static resources and let a live server vend pages, frames, and xhr
> responses for data). The trouble is the feature set doesn't let you
> associate a page that is not stored in an appcache with an appcache.

The static resources should be tied to the manifest file, not the main page.
So, it should be possible for different pages having the same manifest.
The manifest file only concerns those files listed inside it.

I don't see a reason why we need to associate a manifest with a page?
Manifest can be stand alone file, like Java's jar file for example.
A Java jar file doesn't need a main class to be specified (a manifest
doesn't need a main page).
In case the jar file specify the main class (a manifest then associate
the main page to the jar file).

> What if there was a syntax that allowed you to make that association? Something
> like...
> <html useManifest="xxx">
> ... where the page would "use" the cache indicated by manifest but not be
> added to it.
> Would that fit your use case?

That will behave like using manifest "xxx" but discard the main page
that is specified / tied with "xxx"? Yes, that will fit my use case.
But what I need is even simpler:

Currently by default, the main page is cached even if I specify the
main page in the NETWORK section in the manifest. This basically
violates what NETWORK section should do. If I say the main page should
not be cached, then I should be able to put that main page URL in the
NETWORK section and it won't be cached by the browser, and all my
problems are solved.

So the question is: why the main page MUST be linked with a manifest
and MUST be cached even if I specified it in the NETWORK section?

Felix Halim

Michael Nordman

unread,

Sep 29, 2010, 1:35:36 AM9/29/10

to Felix Halim, Eric Bidelman, chromiu...@chromium.org

On Tue, Sep 28, 2010 at 9:28 PM, Felix Halim <felix...@gmail.com> wrote:

On Wed, Sep 29, 2010 at 11:29 AM, Michael Nordman <mich...@google.com> wrote:
> I hear your frustration. The design center for the application cache really
> is caching the so called "single page app" completely for offline use. That
> is a very narrow use case and it sounds like you bust out of those lines on
> two dimensions: multi-page, not for offline use. So it doesn't surprise me
> that the feature set is not well formed for your use case.

I think the use case I have wider usage: most (existing) web pages are
not designed as single page app. I don't know the statistics, but I
think things like .js, .css, and images are 99.999% do not change. So
even a "not modified" header will cost unnecessary round-trip cost.
Let say the user press Ctrl+F5 (what they want is to refresh the main
page, and not other things).

Absolutely, you're interested in something that is more generally applicable.

In my case I have a page with quite big javascript, css, and images
and I don't want the user to reload everything (even if they press
Ctrl+F5).

> I'm not sure you can take advantage of the appcache feature set as it
> current stands for your use case? Some changes to the feature set probably
> could make it useful for your use case, not that this does you any good
> right now.

One thing in the feature set is that to not cache anything in the
NETWORK section of the manifest file, that means including the main
page (if the main page is listed in the NETWORK section).

Resource that would fall into a network namespace can end up in the cache if they are explicitly listed or are implicitly added by way of being a "master entry".

It sounds like you want a spec change to NOT implicitly add a master entry if if they fall into a NETWORK namespace. This seems like a reasonable behavior to want.

The relevant parts of things are...

http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#downloading-or-updating-an-application-cache

I think you want some new words in step17 of the update logic.

Sometimes additions are easier to make than changes to existing behaviors, this is why I mentioned a new syntax to try to accomplish what you want. Another addition that maybe could accomplish what you want w/o changing the behavior if existing content is a new section in the manifest that acts like you want... like the NETWORK section, but a little different... master entries that fall into that section don't get added to the cache... something like...

NON_CACHEABLE_MASTERS

>> its far better if the main page is NOT CACHED at all!
> That makes sense for what it sounds like you want to accomplish (just cache
> the static resources and let a live server vend pages, frames, and xhr
> responses for data). The trouble is the feature set doesn't let you
> associate a page that is not stored in an appcache with an appcache.

The static resources should be tied to the manifest file, not the main page.
So, it should be possible for different pages having the same manifest.
The manifest file only concerns those files listed inside it.

I don't see a reason why we need to associate a manifest with a page?
Manifest can be stand alone file, like Java's jar file for example.
A Java jar file doesn't need a main class to be specified (a manifest
doesn't need a main page).
In case the jar file specify the main class (a manifest then associate
the main page to the jar file).

The association of a particular cache to each page is a fundamental aspect of the appcache feature set.

The reason to "associate" a cache with a loaded document is that subresources will only load from the single appcache, if any, associated with the page. The reason for this is that there can be multiple versions of the same 'url' stored in the appcache system. Which one is loaded depends on which page is doing the loading.

> What if there was a syntax that allowed you to make that association? Something
> like...
> <html useManifest="xxx">
> ... where the page would "use" the cache indicated by manifest but not be
> added to it.
> Would that fit your use case?

That will behave like using manifest "xxx" but discard the main page
that is specified / tied with "xxx"? Yes, that will fit my use case.
But what I need is even simpler:

Currently by default, the main page is cached even if I specify the
main page in the NETWORK section in the manifest. This basically
violates what NETWORK section should do. If I say the main page should
not be cached, then I should be able to put that main page URL in the
NETWORK section and it won't be cached by the browser, and all my
problems are solved

So the question is: why the main page MUST be linked with a manifest
and MUST be cached even if I specified it in the NETWORK section?

Felix Halim

Felix Halim

unread,

Sep 29, 2010, 3:02:12 AM9/29/10

to mich...@chromium.org, Eric Bidelman, chromiu...@chromium.org

I think the use case can be far more wider...
Let me rewrite my use case:

Suppose I want to use jQuery and jQuery UI, this is what I need to
specify in the mainpage.php :

<!doctype html>
<html lang="en" manifest="my.manifest">
<head>
<meta charset="utf-8" />
<title>Whatever</title>
<link rel="stylesheet"
href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.4/themes/cupertino/jquery-ui.css"
/>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.4/jquery-ui.min.js"></script>
</head>
<body>
... other <img> tags...
</body>
</html>

And this is the "my.manifest" content:

CACHE MANIFEST

Now wouldn't it be great if there is a manifest somewhere, let say:

http://jquery.com/jquery.ui.cupertino.manifest

Then all I have to do is to include that manifest in my html, and viola...
My sites (and all other sites that i'm viewing that also uses that
jQuery manifest)
only need to download the jQuery libraries (and most importantly,
those little theme images) only ONCE.
Even if I press Ctrl + F5, what I want to reload is my site, not
jQuery's libraries.
This can even be far faster than hosting the jQuery files in CDN.

On Wed, Sep 29, 2010 at 1:35 PM, Michael Nordman <mich...@chromium.org> wrote:
> It sounds like you want a spec change to NOT implicitly add a master entry
> if if they fall into a NETWORK namespace. This seems like a reasonable
> behavior to want.

Yup.. It "was" all I want.

But after some thought, it's better to introduce different type of manifest...
Manifest for libraries.. that 100% do not change. (see below)

> The relevant parts of things are...
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#downloading-or-updating-an-application-cache
> I think you want some new words in step17 of the update logic.
> Sometimes additions are easier to make than changes to existing behaviors,
> this is why I mentioned a new syntax to try to accomplish what you want.

I know that changing the spec will cause major headache...
But the use case above will be very common...
And I think many people will try including the main page into the
NETWORK section and found it doesn't work...

> Another addition that maybe could accomplish what you want w/o changing the
> behavior if existing content is a new section in the manifest that acts like
> you want... like the NETWORK section, but a little different... master
> entries that fall into that section don't get added to the cache...
> something like...
> NON_CACHEABLE_MASTERS

I think what I'm proposing is something new...
The new jQuery library use case I mentioned above, is special that is,
they 100% do not change.
If they want to change, they change the version number, hence has to
be in different manifest file name.

> The association of a particular cache to each page is a fundamental aspect
> of the appcache feature set.
> The reason to "associate" a cache with a loaded document is that
> subresources will only load from the single appcache, if any, associated
> with the page. The reason for this is that there can be multiple versions of
> the same 'url' stored in the appcache system. Which one is loaded depends on
> which page is doing the loading.

Yes, I understand that if we don't associate cached files to the page
that loads them,
then it may be a case that a cached file get changed/updated by other
page that also loads them,
thus making the first page that loads them inconsistent.
So, yes I agree that the current model that ties the cached files to
the page that loads them is GOOD.

However, we should have another type of manifest that deals with a use
case that the cached files are 100% static and do not change.
These type of manifest can be included without fear of inconsistent
because the cached files in it do not change.

I'd like to have a special manifest like:

That will make all the files listed in xxx into a single zip file.
Later, any pages that loads that manifest, the browser only need to
unzip the files.
This of course... will not cache the main page :P

How about that?

Felix Halim

Michael Nordman

unread,

Sep 29, 2010, 3:29:02 PM9/29/10

to Felix Halim, Eric Bidelman, chromiu...@chromium.org

This is reminding me of HTML Resource Packages.

http://www.mail-archive.com/wha...@lists.whatwg.org/msg22622.html

Felix Halim

unread,

Sep 30, 2010, 5:09:23 AM9/30/10

to mich...@chromium.org, Eric Bidelman, chromiu...@chromium.org

IMHO, HTML Resource Packages seems obtrusive and not efficient for update:

1. Why do developers need to explicitly create a zip file?
It's better off using simple manifest file to list files need to be
"packaged" and let the browser zip them.

2. Changes in any of the file inside the package forces to redownload
the whole zip package.
If we use "immutableManifest" and assume the file in the package to be
100% immutable, then the only way to update is to change the filename,
and update the manifest list. Thus, only files which name changes get
updated.

Felix Halim

Reply all

Reply to author

Forward