I am using browser cache to store my response data, but wanted to know how feasible it is to store the data in browser cache. Can anyone explain the following:
1. Is their a guarantee that the data will be cached for specific time, if I am storing only JSON data(can be huge).
2. What is the maximum size limit of browser cache.
3. Is my data cross domain accessible?If yes is their a way I can protect it?
4.Does the result vary from browser to browser?
There are two main storage method in modern browsers, localStorage and sessionStorage, in your case I assume you are using localStorage.
For localStorage:
the data stored will be persistent as long as the user not clearing the data or you remove them using localStorage.removeItem()
the maximum size of localStorage varies from browsers, basically there is at least 2.5MB. details in this post
localStorage works just like cookies, so you don't want to store any sensitive stuff, SSL between clicent and server is recommended
IE 8 and above, Chrome 4, Firefox 3.5, Opera 10.5 and Safari 4 have already implemented this API
Details about localStorage in this link
Related
I am working on a prototype where we need to support offline data modification of web application, the application is expected to sync back the data when an internet connection is restored. I have taken a look at various HTML5 in-browser storage option and indexeddb looked like the one I wanted. But I am not sure if the data will be persisted between browser close. Is that possible? One more question if I delete the cookie of the browser, will data in indexedDb will be wiped out? My initial tests shows data gets deleted on cookie clear of browser.
If indexeddb is not a viable option, are there any other alternatives to it which can persist data when internet connection is not available?
As per specification database created with indexedDB should be persistent acrross navigation and browser session.
But current implementation is like persistent cookies. So removal of cookies might remove your database too.
As per google chrome indexedDB is a type of temporary storage.
Chrome: https://developer.chrome.com/apps/offline_storage
For microsoft & firefox it is persitent :
Microsoft: https://msdn.microsoft.com/en-in/hh563494.aspx
Firefox: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
Check supported browsers before use.
http://caniuse.com/#search=indexeddb
It isn't dependent on a cookie, though if you need to know who the user is (likely) you'll probably end up using a cookie of some variety...
As for offline sychronization... I thought about this a lot previously and created a project... The documentation for it is detailed and explains why and how... It may help, or at least give you things to think about. It has very recently been updated to support IndexedDB!
http://forbesmyester.github.io/SyncIt/index.html
In this space there is also RemoteStorage ( they were/are looking at using SyncIt + other bits in the project going forward ), Hood.ie and the commercial FireBase in this field.
I am using the following to save a random value in the local storage that will stay until the cache is cleared
localStorage['mkey1'] = Math.floor(Math.random()*801);
however when on mobile devices this does not work if the user closes the browser app, the cache is deleted. This of course is a result of the problem that the cookies in mobile devices are more like session cookies rather the desired expiration date I set to the cookie.
I have came across different sources like
https://danq.me/2012/04/24/visitor-tracking-without-cookies/
and
http://robertheaton.com/2014/01/20/cookieless-user-tracking-for-douchebags/
but I want to use plain Javascript, no Sinatra.
Local Storage should persist on all browsers until it is cleared, unless the browser doesn't support it; are you using a supported browser on the mobile devices you are testing? http://caniuse.com/#search=localstorage
Looking for advice/options for having persistent local storage using both Firefox and Chrome allowing me to save 50MB+ data. I would be storing dynamic terrain data for a WebGL game, so it wouldn't be necessary for the server to send the whole data every time the player connects. I could just update the old parts.
I thought about using an IndexedDB however Chrome doesn't allow you to increase the quota (unlike Firefox) so I wouldn't be able to store any large data. Chrome allows you to use the FileSystem API which would solve my issue however Firefox does not support it.
So it seems either way it wouldn't work. Is my only option to use the FileSystem API for Chrome and the IndexedDB for Firefox? Does anyone have any better ideas?
This info is what I've read from Mozilla's Blog and Google's Dev Site but that may be outdated now, so please feel free to correct me. Thanks!
I agree with the other comments about caching and the Chrome/Firefox marketplaces, and they may ultimately be better solutions for you. However, to answer your original question...
IndexedDB in Chrome is definitely not limited to 5 MB. You can store far more than 50 MB in IndexedDB in both Firefox and Chrome, assuming the user has enough hard drive space. Higher amounts of IndexedDB storage are regularly reached in this game I wrote. On my computer, I currently have over 500 MB stored in IndexedDB in Chrome for that one domain.
You did correctly link to https://developers.google.com/chrome/whitepapers/storage and it is quite confusing, but as I understand it, basically the upper limit is 10% of the free space on the hard drive. Another caveat described on that page is that IndexedDB is technically "temporary" storage that the browser might delete if space is running low, but in practice this seems to rarely happen (YMMV).
localStorage is limited to 5 MB (I think this was on Chrome) and you can request more space for every new 5 MB through dialog boxes.
Both localStorage and IndexedDb are created for interactive data. Because it looks like the data is not modified on the client-side your options are
Using the application cache (as mentioned in the comment)
Serving the data with cache forever HTTP headers (like 10 years), have unique URLs for new resource versions and let the browser re-download the data when it goes out of the cache (recommended)
Deploy your HTML5 application as a web app, downloads available from Chrome Store and Firefox Marketplace
I want to store some data client side. Cookies are my first inclination, but they get sent with every request, right? Is there a way to store data without it being transferred? I don't necessarily want to add 10-20k of overhead for every request. Is the only alternative HTML 5 webstorage and how many browsers have adopted that?
html5 storage is widely deployed
HTML5 STORAGE SUPPORT
IE FIREFOX SAFARI CHROME OPERA IPHONE ANDROID
8.0+ 3.5+ 4.0+ 4.0+ 10.5+ 2.0+ 2.0+
you can find out more # http://diveintohtml5.ep.io/storage.html
No, not all cookies get sent with every request. You can check to see if a cookie exists, if not create it, and if so, read it. Cookies are still a good cross-browser option for small amounts of data.
http://fsojs.com supports robust file storage client-side, but only works with Chrome at the moment
As you have mentioned, cookies are an options and so is web storage in the HTML5 spec. There's also the ability to use Flash to store data with the added benefit that this data persists across multiple browsers on the same machine, but the drawback that you'll need a fallback for users who don't have Flash.
Personally, keeping the data on the server (identified by the session id or cookie) would be my way to do it, you have control of the data and don't have to worry about losing it when the user clears their cache or switches machines/devices. It's also the most fault-tolerant because it doesn't rely on browser features and/or plugins (other than perhaps cookies).
One more thing, if you're looking for an abstraction of client-side data storage that uses all of the above (cookies, flash, web storage) check out Evercookie
This is not so much a technical question as a question of practice: browser storage doesn't seem to have the same browser behaviour as cookies.
For example:
In Firefox 3.6, sessionStorage is not shared between tabs within the same browser session.
localStorage can never be set to expire, while sessionStorage can never persist.
If a site uses cookies for the session, they are shared between tabs.
If a cookie is set to expire, then it expires after a certain date.
It makes sense that it is not 'like for like', however this means that we may need to mix and match our variable storage solutions depending on need. Your thoughts and opinions on the benefits/pitfalls of either would be appreciated.
Background:
On the website we are currently developing, we decided to implement progressive enhancement using browser storage (sessionStorage and localStorage) with a cookie fall-back. Our reason for doing this is simply as a learning exercise, but moving forward this should help us on mobile platforms and situations where cookies are not usable (we are already storing our assets on a cookie-less domain, so this isn't a motivator).
To do this, we have created a class which has set, get, remove and clear methods which store the application variables within a JSON string (this allows us to group values in a hierarchy). For browsers which don't have a JSON parser we use Crockfords JSON plugin.
At run time the storage class works out if the user's browser supports browser storage, otherwise sets the functions to write to cookies instead. Due to the inconsistencies already highlighted (plus others I am unaware of), this 'like for like' progressive enhancement is actually false.
Edit: Another browser vaguary: if IE 8 is running in IE 7 standards mode it supports localStorage and sessionStorage, where standalone IE 7 does not(!).