Analysis of local storage

Web apps do seem to be a little bit more than desktop apps for local storage. In desktop applications, you can use files such as INI or XML to save your configuration and data, or even use a small, embedded database to save your data, and for a long time, we can only use cookies, a flawed but irreplaceable thing. However, with the development of the Internet, local storage technology has been developing, but there is no technology to meet the demand, until the advent of Web storage.

Let's look at some of the more common local storage technologies.

Cookies

This invention by Netscape's former employee Lou Montulli in March 1993 has so far been widely used on various websites, which we use to save the login status, use it to save the browsed items, use it to save the shopping cart items, and so on.

There are several specifications for cookies at this time:

• Netscape Cookie Draft: Is the earliest cookie specification and also the basis of RFC2109. However, it is still a big difference from RFC2109, so there are some compatibility problems with some servers.
• RFC2109: Based on the first official cookie specification published by the web. In theory, all servers are subject to this specification when dealing with version 1 cookies. Unfortunately, because this specification is too restrictive, many servers do not correctly implement this standard or are still using the Netscape cookie draft.
• The second version of the Rfc2965:cookie specification points to a lack of cookie version 1 in RFC2109. RFC2965 's goal is to eventually replace RFC2109.

To learn more about cookies You can study these specifications, but this article will not go into it, here are a few specifications in addition to literacy is mainly to explain a problem, what is a cookie? That's what Netscape's Cookie says in his draft:

A Server, when returning an HTTP object to A client, may also send a piece of state information which the client wil L Store. Included in this state object was a description of the range of URLs for which this state is valid. Any future HTTP requests made by the client which fall on that range would include a transmittal of the current value of th The E state object is from the client back to the server. The state object was called a cookie, for no compelling reason.

Let's look at the browser, how the Web server interacts with cookies:

• When we use a browser to access a Web site, we want the server to initiate a request.
• Filters out the cookies that need to be sent to the server based on the URL of the request and the properties of the cookie itself (there may be no cookie, of course).
• If there are multiple cookies, the order in which they are sent is also determined.
• The cookies that need to be sent are included in the header of the HTTP message to the server.
• Then to the answer stage, the server will send back a reply packet header, the packet contains cookie information.
• The browser parses this cookie, including the name, value, path, and so on.
• Finally, save the cookie locally.

As for which cookies are sent to the server, there is a set of rules, such as domain name selection, path selection, and Max-age selection, which can be found in the RFC2109, and this will not unfold.

As can be seen from the above, each HTTP request, the cookie will be included in the packet header sent to the server, which is widely criticized by developers of a cookie disadvantage, because this means that each request has virtually increased traffic, especially as the request for pictures of these resources, The accompanying cookie information is completely unnecessary. So now a lot of web site pictures and other static resources will be used by separate domain name operation, so you can separate these domain names for cookie settings. In addition, cookies have the following major drawbacks:

• Security issues. Cookies are passed in plaintext in an HTTP request, and it is not advisable to place important information in the cookie unless the SSL channel is used.
• Size issues. The size of each cookie cannot exceed 4K. The number of cookies under each domain is different depending on the browser.

For some restrictions on cookies, you can refer to an article in Nicholas: The number of cookies allowed under each domain name in the browser:

• IE7 and IE8 are limited to 50.
• Firefox has a limit of 50.
• Opera Limits 30
• There is no limit to Safari/webkit, but an error occurs if the header is larger than the server can handle.

And if the number of cookies is set above the limit, how do the browsers handle it:

• Safari is not discussed because there is no limit to the number of cookies.
• Under IE and opera, the LRU (the Least recently used) method will be used to automatically kick off the oldest cookie to make room for new cookies. IE and opera use this method.
• Firefox is unique: it seems to randomly decide which cookies will be retained, even though the last set of cookies will be retained. So do not exceed the limit of the number of cookies in Firefox.

The total size of the cookie is also different in each browser:

• Firefox and Safari allow up to 4,097 bytes of cookies, where 4,096 bytes are names and values, and 1 bytes are = numbers.
• Opera allows cookies up to 4,096 bytes, which contain names, values, and = numbers.
• IE allows 4,095 bytes, which contain the name, value, and = number.

Note that the byte used here, that is, if it is a multibyte character, will naturally occupy two bytes. In all browsers, if the cookie size is set beyond the limit, it will be ignored or not set.

From the above, we can see that there are some shortcomings of cookies, but some of its shortcomings are also its advantages, such as each request will be put into the packet header sent to the server, it is this feature we can easily transfer sessionid. The advent of cookies has greatly facilitated the development of Web pages, and cookies will continue to play its role for a long time to come. But it is also because of the existence of a variety of cookies, there will be new local storage technology needs to emerge.

UserData

UserData is the product of Microsoft in the first browser war and belongs to a technology in DHTML. Compared to the cookie,userdata in each domain can be stored up to a lot of data, but the specific size depends on the domain's security region:

security ZONE	document Limit (KB)	domain Limit (KB)
local Machin E	$	1024x768
intranet	up	10240
trusted Sites		1024x768
internet		1024x768
restricted		6

in general, taking into account the circumstances, the safest way is to control the file below 64K. The data of the file is in XML format and is stored in a directory on the system disk, for example, under XP (assuming C is the system disk), and the saved location is C:\Documents and Settings\ user name \userdata or C:\Documents and Settings\ User name \application Data\Microsoft\Internet Explorer\UserData, while under Vista it is saved in C:\Users\ username \appdata\roaming\microsoft\ Under Internet explorer\userdata. UserData supports more than IE5 browsers, to use UserData, you must host an HTML element. In other words, userdata cannot be used alone, but must be attached to an HTML tag and set behavior: 

xml< /th>	<prefix:customtag id=sid style= "Behavior:url (' #default #userdata ')"/>
html	<element style= "Behavior:url (' #default #userdata ')" ID=SID>
scripting	object.style.behavior = "url (' #default # UserData '
	object.addbehavior ("#default #userdata")

However, it is important to note that not all HTML tags can be used for userdata, such as binding UserData to HTML, head, title, or a style for storing when an error occurs.

UserData data will persist until it is deleted or expires. and security-based considerations, a UserData store can only be used for the same directory and to store the same protocol.

Like cookies, UserData's data is not encrypted, so it is not recommended to keep important information in it.

UserData has progressed much more than cookies in local storage of data, but it has a fatal disadvantage: only IE is supported. On this point, it is doomed that UserData does not have too much to do, it can only be used in conjunction with other local storage technology compatible with the low version of IE.

UserData specific ways to use this is not in-depth, the details can be found in Microsoft's documentation.

Local Shared Object

In 2002, Adobe introduced a new feature in Flash6 and unfortunately acquired a confusing name: "Flash Cookies". In Flash, however, this feature is called the local Shared objects or LSO more appropriate. Simply put, this technique allows flash objects to store 100KB of data on each domain name.

In 2005, Brad Neuberg developed an early flash-to-JavaScript bridging prototype interface called Ajax Massive Storage System (AMASS), but is subject to the limitations of flash technology.

In 2006, with the introduction of Flash 8 's externalinterface, it became easier and faster to access LSO in JavaScript. Brad rewritten the amass and integrated it into the popular Dojo tool framework, named Dojox.storage. At the same time, this technology also allows each domain name to store 100K of data, and beyond this limit to increase to the next size level (1MB,10MB, etc.), will pop up a prompt to let the user confirm.

Adobe Flash Player does not allow third-party LSO to share across domains. For example, a www.example.com LSO cannot be read by www.example2.com. However, the first-party web site can transmit data to third parties through settings on a dedicated XML file.

Users can disable LSO through the Global Storage Settings panel on the Adobe website, or right-click Flash Player to adjust the settings for each site in the settings. The following method also allows the user to delete the LSO. Of course, users can also delete LSO manually or with third-party software.

Until version 10.1,adobe Flash player supports the browser's privacy mode, supported browsers include Chrome,firefox,ie and Safari.

lso resolves some of the above mentioned cookies, such as size, security, and so on. Unlike cookies, LSO is saved as a binary file (although variable names are readable). As an alternative to local storage, LSO has a number of advantages, but the disadvantage is also obvious, that is, it needs to install Flash plug-in. Although the popularity of Flash is very high now, but this technology relies on plug-in has not solved the root cause of the problem, and in order to use this scheme, we have to introduce additional SWF and JS files.

P.s. I don't like flash very much.

Gears

In 2007, Google launched the Gears project. Gears is an open-source browser plug-in that aims to provide additional compatibility features for the browser (for example, the Geolocation API for IE). Gears provides an API for embedding an SQLite-based SQL database. With the user's permission, gears can store data with no size limits in the database. Gears mainly has the following characteristics:

	Let Web apps interact more naturally with the desktop.
	Local storage with a full search capability database.
	Run JavaScript in the background to provide performance.

So, local storage is actually just one of the features of gears. An embedded database is more than enough for local storage, but like flash, gears is just a plug-in, or a plug-in that is not comparable to the popularity of Flash. And as a plugin, its support for browsers is not enough, we look at its browser support situation:

• Firefox 1.5-3.6
• Internet Explorer 6.0-8.0

There is a reason for this, of course, because the Gears project has stopped updating.

In 2010, Google officially announced a gradual abandonment of its support for gears and shifted its focus to HTML5 ...

Globalstorage

This is a global object (Globalstorage) that maintains a variety of public or private storage spaces (for example, between multiple pages and browser sessions) that can be used to hold data for long periods of time. Currently only Firefox is supported.

Globalstorage is not a storage instance, but a storagelist instance that contains Storageobsolete instances. Give me a chestnut:

• globalstorage[' developer.mozilla.org ')-all subdomains below developer.mozilla.org can be read and written by this storage object.
• globalstorage[' mozilla.org '-all pages under the mozilla.org domain name can be read and written through this storage object.
• globalstorage[' org '-all pages under the. org domain name can be read and written through this storage object.
• globalstorage[]-any page under any domain name can be read and written through this storage object.

Firefox 2 allows access to objects that are stored at a higher level than the current document's domain name, for example, you can access mozilla.org or org storage objects on developer.mozilla.org. However, because of the security factor in Firefox 3 and above is no longer allowed, you can only access the current domain name of the storage object.

Web Storage

Given the variety of local storage scenarios, the emergence of a more robust local storage technology seems to be a trend-compliant thing. WEB Storage is designed to provide a larger, more secure, and easier-to-use storage method.

One thing to note: we say that Web storage always think of it as something HTML5, in fact, it is not part of the HTML5 specification, it has its own independent specification.

Web storage can be divided into local storage and session storage. The local storage provides 5MB of storage space, while Sessiong storage is not even limited. Let's take a look at what local storage can do for us:

• Reduce network traffic
• Noticeably faster display speed
• Cache data when RPC is called
• Load cached data at startup (faster boot speed)
• Save temporary State
• Recovery of state when applying transitions
• Prevent loss of work when the network is disconnected

Local storage with session storage in addition to storage space, in the life cycle and storage events and other characteristics of the performance is not the same:

The data type that the the

STORAGE Type	size limit	life cycle	supports for	availability of other windows and tabs
Localstorage	Each browser has a limit of 5MB per app. Depending on the Web Storage specification, users can increase this limit as needed, but only a handful of browsers support it.	Saved on the hard drive until deleted by the user or by the app.	All windows and tabs that are shared with browsers running the same web app.	A string that supports only key-value pairs.
Sessionstorage	Only limited by system memory	Only live in Windows or tabs that use it	can only be accessed by the window or tab that created it	A string that supports only key-value pairs.

As you can see, session storage is just a conversation-level store, and only the window or tab of the same session can access it, and the session end data is destroyed at the same time. The local storage is a persistent store, even if the browser data is turned off, and the data can be shared between multiple windows and tabs.

Let's look at how local storage shares data in a browser:

Each web app on each browser has its own localstorage with a size limit of 5MB and can be shared across all of the windows and tabs on this browser. For example, suppose you run MyWebApp on Chrome, and if you run MyWebApp on multiple tabs and windows, they share localstorage data with the same size limit of 5MB. If you open the same app in another browser, such as Firefox, the new browser will have its own localstorage for sharing the windows and tabs on it. Take a look at the picture below:



Localstorage can only store key-value pairs of string-type data, and if you want to save other types of data, you can only convert the data to a string when you save it, and then convert it back when you read it. Like cookies, localstorage and sessionstorage can be detected by tools such as Web Inspector on developer Tools,sarafi on Chrome. With these tools, users can remove saved data or view what data is saved on the page they are visiting.

Localstorage is not a secure store, and its saved data is not encrypted, and it is not appropriate to keep some sensitive data.

Another important feature of WEB storage is the storage event. When the data of Localstorage or sessionstorage is saved, modified or deleted, the storage event of the current window or tab is triggered. The storage event object that is triggered contains the storage object, URL, and key value before and after the event occurs. Note that while the specification requires storage events to be triggered by all windows or tabs in the same browser, only a handful of browsers implement this feature. In addition, if the storage is emptied, then the event will not contain any information about the value of the deleted key.



The Storageevent object contains the following methods:

Method	Description
GetKey	Returns the key that was modified.
Getnewvalue	Returns the modified key value, or null if the value is not modified or if storage.clear () is called.
Getoldvalue	Returns the value of the key before being modified, or null if the value is not modified or if storage.clear () is called.
Getstoragearea	Returns the Sessionstorage or Localstorage object that triggered the event.
GetURL	The URL of the page that triggered the current store event.

The browsers that currently support Web Storage are as follows:

Summarize

As can be seen, the local storage has been developing, especially the HTML5 phase of the Web Storage, is a relatively perfect implementation. However, the popularity of HTML5 is still in the future, only a relatively new browser to support the Web Storage, and some even if support Web Storage does not fully support the Storage event, in order to be compatible with most browsers, it must be used in conjunction with other local storage technology, For example, browsers that do not support Web storage, such as IE6 and IE7, use UserData, while the lower version of Firefox uses Globalstorage. At present, there are many JS libraries to implement this function, such as: Store.js, Ustore.js, Box.js and so on.

Analysis of local storage