DOM exception error 11 on swapCache() - javascript

I am playing with an application cache and having problems with the swapCache function.
I have created the world's simplest cache manifest file:
CACHE MANIFEST
# Timestamp: 2013-03-01 11:28:49
CACHE:
media/myImage.png
NETWORK:
*
Running the application for the 1st time gives me this in the console:
Creating Application Cache with manifest http://blah_blah/offline.appcache
Application Cache Checking event
Application Cache Downloading event
Application Cache Progress event (0 of 1) http://blah_blah/media/myImage.png
Application Cache Progress event (1 of 1)
Application Cache Cached event
All well so far. Then I swap out the image and change the timestamp in the manifest file and get the following:
Adding master entry to Application Cache with manifest http://blah_blah/offline.appcache
Application Cache Downloading event
Application Cache Progress event (0 of 2) http://blah_blah/media/myImage.png
Application Cache Progress event (1 of 2) http://blah_blah/Widget/?invoke=myWidgetFunctionName
Application Cache Progress event (2 of 2)
Application Cache UpdateReady event
At which point the applicationCache.swapCache() function is called giving me a DOM exception 11 error.
MIME types all correctly configured on the webserver.
Anyone got any ideas / can point me in the right direction?
(I have read all the commonly linked appcache stuff online and can't see what am I doing wrong)
Thanks!
EDIT:
As I mentioned in the comments below, setting the expires headers on my web server for *.appcache files to expire immediately seems to have it working although I am still getting the DOM exception error(!?). I found the following blog entry which may help:
Possible Fix for Offline App Cache INVALIDSTATEERR
...but I have no idea how to set the MIME types client side. My google-Fu skillz have deserted me. Anyone?

I had the same issue. For a while I just disabled the cache if the browser was not chrome, but then I decided to try again, setting the mime-type as suggested. Firefox no longer throws an exception when I call swapCache(), and the whole refreshing process now works as expected. The mime-type has to be set server-side since the request isn't initiated from your web page, but the browser, so you have no control over how it reads the response. You have a couple options here. If you are using apache or IIS, you can do as koko suggested. If you are using a framework that handles routing for you and you configure the mapping of URLs to responses, such as rails or a python wsgi server, then you can typically set the content type manually. Here is my snippet of what I am using in my Python app using Bottle.py (WSGI based):
# BEFORE
#bottle.route(r"/<path:re:.+\.(manifest|appcache)>", auth=False)
def serve_cache_manifest(path):
return bottle.static_file(path, SITE_DIR)
# AFTER
#bottle.route(r"/<path:re:.+\.(manifest|appcache)>", auth=False)
def serve_cache_manifest(path):
return bottle.static_file(path, SITE_DIR, mimetype='text/cache-manifest')
Bottle comes with a utility function that handles returning static files that I am using. It has an optional parameter to set the mime-type.
tl;dr If you can't add the mime-type to your server configuration, you can almost always set it in your server side code (if you have
any).

I would suggest trying to comment out the catchall NETWORK whitelist.
NETWORK:
# *
The * would seem to require network access for all file, according to
https://developer.mozilla.org/en-US/docs/HTML/Using_the_application_cache
I commented out all NETWORK entries for now for a simple web application of mine and it works well.

Related

Updating Offline Cache (Chrome On Mobile)

Afternoon All,
A bit of background - I'm building a custom calendar for a company where jobs can be scheduled and engineers can access it from their mobile to know when and where they're going. They previously used Google calendar but now want something bespoke.
All is fine until somebody loses phone signal and gets a horrible offline page in Chrome and can't access any information. What I'm wanting to do is have it save an offline version of the calendar but also update it when they re-visit it with a better connection - as job times often change.
I've tried saving the page and enabling offline mode in Chrome but the page doesn't update until you manually clear the cache so no good.
I've tried adding some javascript to hard refresh the page in the hope it clears the browser cache but again it doesn't update the page.
<script>location.reload(true);</script>
I read about cache manifests and have tried that too but although it feels like it wants to work it also doesn't update the page until I go to chrome://appcache-internals and remove the file.
CACHE MANIFEST
/calendar.php
/css/style.css
Neither PHP or Javascript headers work either as they either don't update the file on re-visit or simply don't save any files in the first place.
header("Cache-Control: no-cache, must-revalidate");
<meta http-equiv="Cache-Control" content="no-store" />
As far as I can tell there's no way to manually delete a user's website cache and re-download it and once the cache has been saved there's no way to force it to update. If you set it to expire then it's not there to access and you don't know when they will next have a connection to update so I'm going round in circles.
I've been trying for several hours now to find something that works and can't believe it's not a simple thing to do and therefore I'm now throwing myself on the mercy of you fine coders to point me in the right direction before my boss hangs me from the first floor window.
Many Thanks
UPDATE
Using what Clarence said as a starting point I came up with the following code in my appcache file:
CACHE MANIFEST
CACHE:
/css/bootstrap.css
/css/style.css
/calendar.php
NETWORK:
/calendar.php
# UPDATED: 03-04-2018 15:55:57
What this does is caches the calendar.php file BUT if there is a connection then it has another look at those files under the NETWORK heading so I also put it in there. If the appcache files hasn't changed then the browser doesn't bother looking so I've used the following code to write to the file when a job has been altered:
$manifest = file_get_contents(__DIR__ . '/cache.appcache');
$newFile = substr($manifest, 0, (strpos($manifest, '# UPDATED: ') + 11));
$newFile = $newFile . date('d-m-Y H:i:s');
file_put_contents('cache.appcache', $newFile);
Basically just searches the file for "UPDATED" and inserts a new time thus updating the file and requiring a re-check from returning users.
Somebody might point out this isn't the right way to do it but it seems to work from my tests so would like to thank those that contributed.
Have you tried changing the contents of your cache manifest whenever you change one of the files? The APPCACHE is a bit finicky when it comes to changes in the files and can be troublesome to handle. I usually include a comment with a timestamp and version number just to force it to update in the browser, like so:
CACHE MANIFEST
# 01-01-2001 v1.0 (Change whenever you need to force an update of the cache)
CACHE:
/css/file.css
/js/file.js
NETWORK:
*
FALLBACK:
well the best option would be creating a PWA. This should include the manifest files and Service workers as well. It enables you to cache the content of the websites and update it once the connection has been reestablished. However it is very new and would require a decent amount of research into service workers. If you need any help regarding the development of PWA would be happy to help to an extent
The only way without HTTP-Header is to rename files continuously.
And the depending HTML tag file-name.
So the files are loaded afresh.
With HTTP-Header look here.
How to control web page caching, across all browsers?
You can do this whenever a new change in the calendar was made.

DOMError localforage indexeddb cases?

Today I had an error type: DOMerror exception thrown. Leaving the browser in blank page.
After doing some research I see in w3c that it should be used exclusively for indexeddb exceptions.
I actually removed cookies clear local storage and cache. And the problem does not happen anymore.
This is some more information I have of this Issue in the moment it happen:
message: "The requested version (1) is less than the existing version (2)."
(anonymous function)#app.js?0.1:1
(anonymous function)#vendors.js?0.1:16229
flush#vendors.js?0.1:16513
drainQueue#vendors.js?0.1:14819 DOMError
Where vendors is third party libraries in a bundle, and app is my application bundle.
I am trying to reproduce the error right now, but is hard to reproduce as it looks like a bad handling with persistance data on client, and the client has cleaned cookies / cache / localstorage to keep on working.
When does Dom error exception thrown on an application when using localforage?
"The requested version (1) is less than the existing version (2)."
--> this means your indexeddb database is currently in version 2 and you are trying to open it in version 1.
It is not allowed to open a database in a lower version when working with indexeddb

adding cache file .appcache stops jquery ajax call

I have published a website on azure which usues jquery ajax calls to fetch the data from azure hosted database.
Now my question is this flow is working fine unless and until i add ".appcache" file in it for caching the files locally so that the website can work offline as well. After adding this file it stops working and shows me an error like
net::ERR_FAILED $jquery-1.11.2.js:9659
send $jquery-1.11.2.js:9659
jQuery.extend.ajax $jquery-1.11.2.js:9210
loginservice $authentication.js:94
(anonymous function) $authentication.js:81
clicking on "jquery-1.11.2.js:9659" redirects me to this line in jquery:
xhr.send( ( options.hasContent && options.data ) || null );
can somebody please guide me how does this works? how can use caching and jquery together?
I imagine that the url you are trying to access via jQuery is not one that is listed in the CACHE section of your cache manifest. Remember that, when using appcache, all requests load from the cache and not the server. If a resource isn't cached, you'll get net::ERR_FAILED.
The one exception is for resources listed in the NETWORK section of the file. Try adding the following to your cache manifest:
NETWORK:
*
Try again, and see if the error resolves itself.
This and this are excellent resources.

How to force client reload after deployment?

I'm using the MEAN stack (mongo, express, angular and node). I'm deploying relatively frequently to production...every couple of days. My concern is that I'm changing the client side code and the API at times and I would rather not have to ensure backwards compatibility of the API with previous versions of the client code.
In such a scenario, what is the most effective way of ensuring that all clients reload when I push to production? I have seen that Evernote for example has a pop-up that says something along the lines of please reload your browser for the latest version of Evernote. I would like to do something similiar...do I need to go down the path of socket.io or sock.js or am I missing something simple and there is a simpler way to achieve this?
Update:
AppCache was deprecated summer 2015 so the below is no longer the best solution. The new recommendation is to use Service Workers instead. However, Service Workers are currently still experimental with sketchy (read: probably no) support in IE and Safari.
Alternatively, many build tools now seamlessly incorporate cache-busting and file "versioning" techniques to address OPs question. WebPack is arguably the current leader in this space.
This might be a good use case for using HTML5's AppCache
You'd probably want to automate some of these steps into your deployment scripts, but here is some code you might find useful to get you started.
First, create your appcache manifest file. This will also allow you to cache resources in the client's browser until you explicitly modify the appcache manifest file's date.
/app.appcache:
CACHE MANIFEST
#v20150327.114142
CACHE:
/appcache.js
/an/image.jpg
/a/javascript/file.js
http://some.resource.com/a/css/file.css
NETWORK:
*
/
In app.appcache, the comment on line #v20150327.114142 is how we indicate to the browser that the manifest has changed and resources should be reloaded. It can be anything, really, as long as the file will look different to the browser from the previous version. During deployment of new code in your application, this line should be modified. Could also use a build ID instead.
Second, on any pages you want to use the appcache, modify the header tag as such:
<html manifest="/app.appcache"></html>
Finally, you'll need to add some Javascript to check the appcache for any changes, and if there are, do something about it. Here's an Angular module. For this answer, here's a vanilla example:
appcache.js:
window.applicationCache.addEventListener('updateready', function(e) {
if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
// Browser downloaded a new app cache.
// Swap it in and reload the page to get the latest hotness.
window.applicationCache.swapCache();
if (confirm('A new version of the application is available. Would you like to load it?')) {
window.location.reload();
}
}
else {
// Manifest didn't changed. Don't do anything.
}
}, false);
Alternatively, if AppCache won't work for your situation, a more ghetto solution would be to create a simple API endpoint that returns the current build ID or last deployment date-time. Your Angular application occasionally hits this endpoint and compares the result to it's internal version, and if different, reloads itself.
Or, you may consider a live-reload script (example), but, while very helpful in development, I'm not sure how good of an idea it is to use live/in-place-reloading of assets in production.
I will tell you my problem first then I will recommend a tentative solution. I wanted to force my user to log out and then log in when a production build is been deployed. At any point in time, there will be two versions of software deployed on production. A version which software which FE knows and a version which Backend knows. Most of the time they would be the same. At any point in time if they go out of sync then we need to reload the client to let the client know that a new production build has been pushed.
I am assuming 99.99% of the time the backend would have the knowledge of the latest version of the deployed software on production.
following are the two approaches which I would love to recommend:-
The backend API should always return the latest version of the software in the response header. On the frontend, we should have a common piece of code that would check if the versions returned by the API and that present on the FE are the same. if not then reload.
Whenever a user logs in. the BE should encode the latest software version in the JWT. And the FE should keep sending this as a bearer token along with every API request. The BE should also write a common interceptor for every API request. which would compare the software version in the JWT received from the API request and the
Maybe you can add hash to your client code file name. eg app-abcd23.js.
So the browser will reload the file instead of get it from cache. or you can just add the hash to url.eg app.js?hash=abcd23 but some browser may still use the cached version.
i know rails has assets-pipline to handle it, but i am not familiar with MEAN stack. there should be some package in npm for that purpose.
And i dont think it is really necessary to use socket.io if you want to notify the user their client code is out of date. you can define your version in both html meta tag and js file,if mismatch, show a popup and tell the user to refresh.
Try to limit your js/files to expire within smaller periodic time, ie: 1 days.
But in case you want something that pop-out and tell your user to reload (ctrl+f5) their browser, then simply make a script that popup that news if you just changed some of your files, mark the ip/session who have just reload/told to reload, so they will not be annoyed with multiple popup.
I was facing the same problem recently. I fixed this by appending my app's build number with my js/css files. All my script and style tags were included by a script in a common include files so it was trivial to add a 'build number' at the end of the js/css file path like this
/foo/bar/main.js?123
This 123 is a number that I keep track of in my same header file. I increment it whenever I want the client to force download all the js files of the app. This gives me control over when new versions are downloaded but still allows the browser to leverage cache for every request after the first one. That is until I push another update by increment the build number.
This also means I can have a cache expiry header of however long I want.
Set a unique key to local storage during the build process
I am using react static and loading up my own data file, in there i set the ID each time my content changes
Then the frontend client reads the key with from local storage
(if the key does not exist it must be the first visit of the browser)
if the key from local storage does not match it means the content has changed
fire line below to force reload
window.replace(window.location.href + '?' + key)
in my case i had to run this same line again a second latter
like
setTimeout( (window.replace(window.location.href + '?' + key))=> {} , 1000)
full code below:
const reloadIfFilesChanged = (cnt: number = 0, manifest: IManifest) => {
try {
// will fail if window does not exist
if (cnt > 10) {
return;
}
const id = localStorage.getItem('id');
if (!id) {
localStorage.setItem('id', manifest.id);
} else {
if (id !== manifest.id) {
// manifest has changed fire reload
// and set new id
localStorage.setItem('id', manifest.id);
location.replace(window.location.href + '?' + manifest.id);
setTimeout(() => {
location.replace(window.location.href + '?' + manifest.id + '1');
}, 1000);
}
}
} catch (e) {
// tslint:disable-next-line:no-parameter-reassignment
cnt++;
setTimeout(() => reloadIfFilesChanged(cnt, manifest), 1000);
}
};

405 error not allowed whereas I have javascript error [duplicate]

I am trying to host an ASP.NET MVC4 web application with IIS 7.5. When debugging the app everything works fine (I'm assuming this is because of Windows Authentication).
However, when I publish the app and browse to it I get a 405 Method not allowed error:
POST http://localhost/ 405 (Method Not Allowed)
send
i.extend.ajax
i.(anonymous function)
(anonymous function)
From what I've been reading this is either a problem with the Handler Mappings in IIS or some configuration is needed in the web.config. Either way, I have not found the correct solution.
Could anyone tell me what my web.config should include to all POSTS? And/or how to set up the correct Handler mapping in IIS, as I am new to web development and find the number of options a bit overwhelming.
The piece of javascript that throws the error is the following:
$.post("/", { latitude: locLat, longitude: locLon, username: $('#onlineUsers').attr('itemid') });
A 405 is thrown by IIS when an HTTP verb(GET,PUT,POST,DELETE,HEAD,etc.) is requested and is not supported/disallowed by the designated handler.
You'll need to open the IIS manager -> Default Web Site -> Handler Mappings (Or the handler mappings specific to your web-application)
In here you'll need to play with the handler mappings as one of them is not allowing "POST" verbs.
As you are not posting to any specific page (.aspx, .ashx, etc.), it will be difficult to identify the exact handler that is causing you issues.
Handlers of interest may be:
ExtensionlessUrlHandler-ISAPI-4.0_32bit /64bit
StaticFile
Once you identify the handler your request is being routed to, double click it to open the dialogue.
From there click "Request Restrictions" then "Verbs"
Make sure the appropriate verb is present in the text area.
As I mentioned before, I'm not sure which handler is handling your request as you are not posting to any particular page (you may have URL re-writing in place that is routing your request appropriately).
If the above fails, you may need to check if WebDAV Publishing is installed and remove it (restart required).
Maybe you should modify your post'URl format like this:
$.post('#Url.Content("~/Attach/UpdateAttach")'
some users here are having shared hosting and not dedicated servers, so they might not be able to get access to the IIS control panel..
this is my case and here is what I found..
I have my web application on the root directory created through Godaddy control panel.. and the POST request is acknowledged ..
then I used the FileZilla to create a testing folder for my jquery ..( notice i used FileZilla , so the web application and hence the IIS of GoDaddy is not aware that I wanted this folder to be part of my we application )
then whenever I test this jQuery on this testing folder.. I get that error [405 Method not allowed]..
the solution was extremely simple :
I moved my testing page out of that testing folder created by FileZilla and located it inside a folder that was created through Godaddy control panel ( in this case the IIS will be aware that this page is part of my web application :) )
Hope that will help those on Shared hosting

Categories

Resources