Support SETTINGS: prefer-online in appcache manifest

RESOLVED WONTFIX

Status

()

Core
DOM
RESOLVED WONTFIX
9 years ago
7 months ago

People

(Reporter: frank goossens, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9.2 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Gecko/20090908 Minefield/3.7a1pre

did some testing with html5 offline using Gecko/20090908 Minefield/3.7a1pre (on
win xp) and according to those tests (and my no doubt limited understanding of
how the offline appcache should work) it may have been too early to close this
bug as it seems too much is stored in the offline cache;

an example on http://futtta.be/html5/offline.php

* offline.php:
** has "no-cache" and "expires" headers set in php
** shows server unix timestamp (so page is different at each request)

* manifest.php:
** declares mozchomp.gif as to be cached ("explicit", using "CACHE:")
** prohibits offline.php from being cached ("online whitelist", using
"NETWORK:")

when accessing the page, allowing FF to store data into the offline cache and
refreshing the page 2 times, the html-output of offline.php is also stored in
the offline cache, as the timestamp does not change any more. 

now please correct me if i'm wrong, but caching offline.php should not happen,
(even if it would not have been explicitly excluded in the manifest)?

Reproducible: Always

Steps to Reproduce:
1. load http://futtta.be/html5/offline.php
2. allow FF to store cache
3. refresh page 2 times
Actual Results:  
offline.php is fetched from offline cache (where it should not reside) instead of from network.

Expected Results:  
offline.php should not be in offline cache
Honza, can you look into this?  I can confirm that the steps to reproduce lead to the offline.php loading from the appcache...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.2?
This either belongs in HTML::Parser or Networking::Cache, personally I'm not sure where the bug is. Anyhow, this is only with the HTML5 parser, and it's disabled by default for 1.9.2.
Version: unspecified → Trunk
What does the HTML5 parser have to do with this?  Nothing, as far as I can tell.
Over to Honza, but this doesn't sound critical enough to hold the release for. Let me know if I'm completely wrong here...
Assignee: nobody → honzab.moz
Flags: blocking1.9.2? → blocking1.9.2-
I guess the bug shipped in 1.9.1 already...  <sigh>.

I still think we should fix it to avoid poisoning the feature.
(Reporter)

Comment 6

9 years ago
did some more reading of the spec, this might not be a bug after all (although that would make html5 offline web applications less powerful/flexible then google gears localserver);

* concerning "offline.php" being cached, this might be applicable: "Master entries: Documents that were added to the cache because a browsing context was navigated to that document and the document indicated that this was its cache, using the manifest attribute."
* concerning "NETWORK': this directive seems not to specify which resources SHOULD be fetched online, but rather CAN be fetched online (because "Let online whitelist wildcard flag be blocking." in the spec seems to indicate that nothing can be requested from the internet by default).

But I guess Honza is best placed to confirm if FF3.5.3 conforms to the specs or not.
This seems to be bug in the spec not in Gecko itself. I have already seen this in another (not FF) bug and have fight this myself. When an html page defines a manifest (<html manifest="my.manifest"> then it is cached as a master entry EVEN it has been referred in the manifest as a NETWORK entry. It is also assigned the offline cache to load all resources from.

I'll recheck this and potentially start a discussion on whatwg forum if it is not already there.
Status: NEW → ASSIGNED
(Reporter)

Comment 8

9 years ago
It took me quite some time, but it does seem that the current implementation in FF does follow the spec (except for the fact that the master entry seems to be stored offline on the 2nd hit instead of the 1st).

But the spec would be better off if the wording at least was clearer about the fact that this only works with static pages (which can contain javascript-logic to fetch and display data dynamically).

And it would indeed be even better if some kind of 'blacklist' were made possible in the manifest, in which files can be excluded from being stored (even if "master entry"), as 'network' seems to be a whitelist of files that 'might' be fetched online (i.e. only if not stored).
(In reply to comment #8)
> except for the fact that the master entry seems to be
> stored offline on the 2nd hit instead of the 1st).
> 

If it is true then it is a bug. Can you provide a test case or reference to the code where you see this issue?

To solve your original problem: I'm not sure what you are trying to achieve but it seems that solution for you is to have a main page referring the manifest (i.e. being a master entry always satisfied from the offline cache). This main page will load the dynamic page in an iframe from a specific URL. As I understand the page is always generated by the server. What do you do in case the offline app is really in an offline environment and the server cannot generate the page? What is displayed to user? If you want to display a fallback page then you should use the FALLBACK mapping for the iframe URL. See the spec or mdc documentation.
(Reporter)

Comment 10

9 years ago
with regard to the "master entry" being not cached immediatly; cfr. http://futtta.be/html5/offline.php. the page is taken offline, but the unix timestamp gets updated one more time upon the next refresh.
(Reporter)

Comment 11

9 years ago
wrt "the fact that the master entry seems to be stored offline on the 2nd hit instead of the 1st"; i tested some more, apperantly when you get the dialog asking for permission to store locally and you click on the 'allow'-button, the page is re-fetched. no idea if this is according to spec though ..
(Assignee)

Updated

5 years ago
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
There is 

SETTINGS: 
prefer-online

option now that we don't implement.  And since appcache is now only maintained and not improved according the spec, no one is probably going to implement it.
Assignee: honzab.moz → nobody
Status: ASSIGNED → NEW
Summary: html5 offline caches too much? → Support SETTINGS: prefer-online in appcache manifest

Comment 13

7 months ago
Indeed, in fact we're trying to get it removed per bug 1237782.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.