If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

we sometimes don't check for appcache manifest update if it send no http cache headers

REOPENED
Unassigned

Status

()

Core
DOM: Apps
--
major
REOPENED
5 years ago
3 years ago

People

(Reporter: julienw, Unassigned)

Tracking

Trunk
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
STR:
* install a hosted+appcache app
* change the appcache manifest
* check for an update

Expected:
* a download available event should be triggerred

Actual:
* nothing happens

I checked on my Apache logs that the appcache manifest is not even checked so no wonder.
(Reporter)

Comment 1

5 years ago
Oh, I just saw that the appcache manifest is not checked even if the webapp manifest is changed.

I have the patches for bugs 831644, 832408, 833587 in my tree, I'll try a clean tree to see if this comes from one of these.
(Reporter)

Updated

5 years ago
Summary: we don't check for appcache manifest update when the webapp manifest has not changed → we don't check for appcache manifest update
Could have sworn this was working before. Definitely a regression.
Keywords: regression
(Reporter)

Comment 3

5 years ago
same thinh with a clean tree.

I'm taking this and see if I can figure it out.
Assignee: nobody → felash
Works for me on b2g18. Can you give a test case demonstrating this?
Keywords: regression → testcase-wanted
(Reporter)

Comment 5

5 years ago
I use my app in http://everlong.org/mozilla/selfupdatinghosted/ but it needs manual manipulation. I can put it on github if you want ?
(Reporter)

Comment 6

5 years ago
I don't see it anymore now. Removing the nomination until I see clearer.
blocking-b2g: tef? → ---
If you can't reproduce, then let's close this.
(Reporter)

Comment 8

5 years ago
I actually saw this so please keep it for now.
(Reporter)

Comment 9

5 years ago
Just got it again when trying things for Bug 834338.

Here is the Webapps.jsm log:

I/Gecko   (  110): -*-*- Webapps.jsm : checkForUpdate for http://www.everlong.org/mozilla/selfupdatinghosted/manifest.webapp
I/Gecko   (  110): -*-*- Webapps.jsm : adding manifest etag:"4d40c404ad656"
I/Gecko   (  110): -*-*- Webapps.jsm : Checking manifest at http://www.everlong.org/mozilla/selfupdatinghosted/manifest.webapp
I/Gecko   (  110): -*-*- Webapps.jsm : Got http status=304 for http://www.everlong.org/mozilla/selfupdatinghosted/manifest.webapp
I/Gecko   (  110): -*-*- Webapps.jsm : updateHostedApp http://www.everlong.org/mozilla/selfupdatinghosted/manifest.webapp
I/Gecko   (  110): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json
I/Gecko   (  110): -*-*- Webapps.jsm : updateHostedApp: updateSvc.checkForUpdate for http://www.everlong.org/mozilla/selfupdatinghosted/manifest.appcache
I/Gecko   (  110): -*-*- Webapps.jsm : updateHostedApp: updateSvc.checkForUpdate return for http://www.everlong.org/mozilla/selfupdatinghosted/manifest.webapp - event is offline-cache-update-unavailable
I/Gecko   (  110): -*-*- Webapps.jsm : Saving /data/local/webapps/webapps.json
E/GeckoConsole( 1670): Content JS LOG at http://www.everlong.org/mozilla/selfupdatinghosted/js/install.js:62 in handleDownloadApplied: download applied
E/GeckoConsole( 1670): Content JS LOG at http://www.everlong.org/mozilla/selfupdatinghosted/js/install.js:67 in handleDownloadApplied: no download is available


The two last logs are from my application, it means that we get the downloadapplied event on the app.

This log shows that we're correctly doing the check in Gecko but I'm still not seeing this in my server logs.

I wonder if there could be some HTTP cache kicking in here. I have no specific expires headers so maybe some heuristic are used as for other files ?

Here are the complete headers for this appcache file :

julien@tangkou:~$ curl -I http://www.everlong.org/mozilla/selfupdatinghosted/manifest.appcache
HTTP/1.1 200 OK
Date: Fri, 25 Jan 2013 22:02:43 GMT
Server: Apache/2.2.16 (Debian)
Last-Modified: Fri, 25 Jan 2013 21:58:28 GMT
ETag: "4d42407067357"
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/plain

We see that the content-type is (incorrectly) text/plain, so maybe the heuristics for text/plain are used ?

Honza, what do you think ?
(Reporter)

Updated

5 years ago
Flags: needinfo?(honzab.moz)
(Reporter)

Updated

5 years ago
Summary: we don't check for appcache manifest update → we sometimes don't check for appcache manifest update if it send no http cache headers
(Reporter)

Comment 10

5 years ago
marking duplicate just as Bug 834338
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 830588
(Reporter)

Updated

5 years ago
Flags: needinfo?(honzab.moz)

Updated

5 years ago
Keywords: testcase-wanted
(Reporter)

Comment 11

5 years ago
Reopening because the behaviour for OWA updates is different than for appcache-manifest-in-html-tag updates.

My STR:
* install the app in http://everlong.org/mozilla/selfupdatinghosted/
* change the appcache manifest (and the webapp manifest if you want, it doesn't change anything)
* check for update

Expected:
* we should have an update

Actual:
* we don't
* I observed in Apache logs that I only see the conditional request for the webapp manifest. I also snooped into the network traffic using ngrep and saw nothing except this request. So, no request for the appcache manifest.

I've observed that it works after some time, so I suspect this is a case of heuristic caching. However, we shouldn't do an heuristic caching here because the appcache manifest is served with an ETag. Here are the complete headers for this file :

$ curl -I http://everlong.org/mozilla/selfupdatinghosted/manifest.appcache
HTTP/1.1 200 OK
Date: Wed, 30 Jan 2013 10:36:31 GMT
Server: Apache/2.2.16 (Debian)
Last-Modified: Wed, 30 Jan 2013 10:32:40 GMT
ETag: "4d47f07a284b5"
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/plain

I also observed that everything works fine with the application in http://everlong.org/mozilla/selfupdatinghostednocache/ which has an .htaccess to force an update. Here are the headers for this application's manifest :

$ curl -I http://everlong.org/mozilla/selfupdatinghostednocache/manifest.appcache
HTTP/1.1 200 OK
Date: Wed, 30 Jan 2013 10:42:12 GMT
Server: Apache/2.2.16 (Debian)
Last-Modified: Fri, 25 Jan 2013 22:21:46 GMT
ETag: "4d4245a5c8e96"
Accept-Ranges: bytes
Content-Length: 88
Cache-Control: max-age=0
Expires: Wed, 30 Jan 2013 10:42:12 GMT
Content-Type: text/plain

I also tried a pure webapp-with-appcache (I mean, not a OWA) in http://everlong.org/mozilla/appcache/, and we _don't_ check for an appcache update (after the initial download). However, Desktop Firefox (20) _does_ check for an appcache update in the same situation.

So now I'm quite sure the problem is not in our OWA update mechanism but in the actual appcache manifest update mechanism in Firefox OS.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 12

5 years ago
(In reply to Julien Wajsberg [:julienw] from comment #11)
> 
> I also tried a pure webapp-with-appcache (I mean, not a OWA) in
> http://everlong.org/mozilla/appcache/, and we _don't_ check for an appcache
> update (after the initial download). However, Desktop Firefox (20) _does_
> check for an appcache update in the same situation.

I mean I tried this in Firefox OS' Browser app, which stores the appcache without user consent per Bug 835379, and with Desktop Firefox, and the behaviors are different in my case.
(Reporter)

Updated

5 years ago
Assignee: felash → nobody
What is the current priority of this bug?
(In reply to Honza Bambas (:mayhemer) from comment #13)
> What is the current priority of this bug?

Not a priority at the moment.

Comment 15

3 years ago
Is there a work-around for this bug? i.e. I already specify this in the .htaccess file, to no avail. The file is still cached on Firefox (not Chrome):
ExpiresByType text/cache-manifest "access plus 0 seconds"

My file is https://writerduet.com/appcache.manifest and the cache header is:
Cache-Control: no-cache

What can I specify to make Firefox not cache this file? I don't know how to test it, since after clearing my cache the bug no longer reproduces. As said above, this sounds like a Firefox caching heuristic problem.
(Reporter)

Comment 16

3 years ago
Are you sure your .manifest file is recognized as text/cache-manifest ? On my system, files with the extension ".appcache" (eg: writerduet.appcache) have this mime type automatically. That might be your issue here.

When I use "curl -I" on your file, I see that the "Expires" header is wrong:
  Expires: Sat, 05 Jul 2014 10:20:58 GMT

So I suspect an error on your server-side.

Note that Firefox is doing what the spec says, and Chrome violates it. I personally believe that Chrome's behavior is saner though.

Comment 17

3 years ago
Thanks for checking it out, but I still see this as a bug, and I'm not certain my planned work-around will work (can't reliably test). The cache expiration time is the same instant as it's requested, so it should never be cached, right? I'm thinking of adding these lines to the .htaccess file (for .manifest), but I'd love it if someone can confirm they'll work around the bug. Thanks!!

Header unset Cache-Control
Header unset ETag
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
(Reporter)

Comment 18

3 years ago
I simply use this in a .htaccess file:

  ExpiresActive On
  ExpiresDefault "access"

But you need to set this only for your file. So

  ExpiresByType text/cache-manifest "access"

should definitely work provided that your file is recognized as text/cache-manifest.

You can try to rename it to "manifest.appcache" (works on my system) but maybe you can use a <Files> directive with my code instead.
You need to log in before you can comment on or make changes to this bug.