CODEWITHSUNDEEP
google-chromehtml5-appcachecache-manifestapplication-cachemanifest.cache
Sriks
Sriks

Reputation: 1699

Application Cache Error event: Manifest fetch failed (4)

I am trying to implement AppCache in my application. I have added the corresponding MIME type in IIS. Please see my below html tag 

<html manifest="example.appcache">

My manifest looks like:

CACHE MANIFEST

Content/img/logo-header.png 
Content/img/img-sprite.png
Content/img/icon-top-nav-sprite.png

NETWORK:
*

When I try to execute my application, I am getting the below error in my chrome console

Creating Application Cache with manifest http://localhost:7520/example.appcache 
Application Cache Checking event 
Application Cache Error event: Manifest fetch failed ***(4)*** http://localhost:7520/example.appcache

Can you please help me how to resolve this issue.

Upvotes: 4

Views: 18790

Answers (6)

Austin France
Austin France

Reputation: 2501

I have just run into this problem, and it turned out to be because my server was returning an internal server error, due to a problem with my server config (.htaccess).

Upvotes: 0

DeveloperX
DeveloperX

Reputation: 302

Just disable the device emulator inside chrome if you are using it or see below the long explanation on how to fix.

Just found the problem for me. I was busy building a mobile site, so while building it I used Google Chrome developer tools for emulating the User Agent / Device emulator.

problem while using device emulator

Once I turned this off this feature it worked just fine. disabling device emulator

The problem seems to be that the user agent being passed to the main loading of the page and the user agent for the manifest does not match thus giving an error as my code would redirect (302) a user if not visiting via a mobile device.

The user was theoretically visiting via a mobile device but Chrome does not send the "fake" user agent set on the device selector through when requesting the contents of the manifest.

So here we get the main page: 127.0.0.1 - - [31/Aug/2016:12:53:58 +0200] "GET / HTTP/1.1" 200 7578 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1"

Then the manifest is retrieved: 127.0.0.1 - - [31/Aug/2016:12:53:58 +0200] "GET /manifest.appcache HTTP/1.1" 200 130 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36"

Then it tries to get the main page to index it but the user agent is incorrect here: 127.0.0.1 - - [31/Aug/2016:12:53:58 +0200] "GET / HTTP/1.1" 302 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36"

Upvotes: 0

Pedro S Cord
Pedro S Cord

Reputation: 1359

What worked for me was simply open the manifest in the notepad and save as UTF-8 enconding that works. Just tell the browser to render as UTF-8 will not do, the file has to be in fact in the UTF-8 encoding.

I also followed the instructions in this blog http://www.codemag.com/article/1112051 for details how to built a offline application.

Upvotes: 0

phnghue
phnghue

Reputation: 1686

It is the silly error, I make some stupid things and it work:

  1. Visit chrome://appcache-internals/ and clear my web cache
  2. Add # v1.0.1 under the CACHE MANIFEST line
  3. Reload

Then I del the new line and the error not come back. @.@

Upvotes: 0

lkurylo
lkurylo

Reputation: 1641

I lost another day to debug this problem. It looks like, the manifest file must be always returned with status code 200 (I had problems with 302) and the manifest itself and all files defined in the manifest must be returned to browser without the header no-store.

Upvotes: 3

Stuart P. Bentley
Stuart P. Bentley

Reputation: 10675

I just ran into this problem on one of my own sites (with error code 4). In the time since the cache had been downloaded, I had instituted a redirect on all URLs on the domain, to redirect to the HTTPS version of the site. It is my suspicion that this error code has something to do with the manifest being unavailable due to a redirect.

In my case, I solved the problem (personally) by clearing the cached files in chrome://appcache-internals, then re-visiting the root site to experience the redirect to the newly-secured version of my domain.

If you are in a similar situation and cannot clear the appcache (say, because you have users who are unaware that they're receiving stale content), you could try changing your site so that requesting the cache manifest at the old URL does not result in a redirect, and instead allows network requests that would allow the browser to download the new version of the page and encounter the redirect. See this question for information on clearing a cache manifest.

Upvotes: 3

Related Questions