Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

width400px

...

Table of Contents
indent20px

Introduction

The Web Storage API includes two related mechanisms for persisting client-side data in a secure manner using the Document Object Model (DOM),  sessionStorage and localStorage. These objects were introduced in Windows Internet Explorer 8.

(warning) Note: For versions of Windows Internet Explorer prior to version 8, persistent data storage is implemented by the userData behavior.

Image RemovedImage Added

DOMstore entries in NetAnalysis 1.5x

What is DOM Storage?

Web Storage is often compared to HTTP cookies.  Like cookies, Web developers can store per-session or domain-specific data as name/value pairs on the client using Web Storage.  However, unlike cookies, Web Storage makes it easier to control how information stored by one window is visible to another.

...

Functionally, client storage areas are quite different from cookies.  Web Storage doesn't transmit values to the server with every request as cookies do, nor does the data in a local storage area ever expire.  And unlike cookies, it is easy to access individual pieces of data using a standard interface that has growing support among browser vendors.

window.sessionStorage

Session storage is designed for scenarios where the user is carrying out a single transaction. The sessionStorage attribute of the window object maintains key/value pairs for all pages loaded during the lifetime of a single tab (for the duration of the top-level browsing context).  For example, a page might have a check box that the user selects to indicate that he wants insurance.

...

(warning) Note:  Although it is allowed by the HTML5 (Working Draft), Internet Explorer 8 does not resume  sessionStorage after browser crash recovery.

window.localStorage

The local storage mechanism spans multiple windows and persists beyond the current session. The localStorage attribute provides persistent storage areas for domains. It allows Web applications to store nearly 10 MB of user data, such as entire documents or a user's mailbox, on the client for performance reasons.

...

Each domain and subdomain has its own separate local storage area. Domains can access the storage areas of subdomains, and subdomains can access the storage areas of parent domains. For example, localStorage['example.com'] is accessible to example.com and any of its subdomains. The subdomain  localStorage['www.example.com'] is accessible to example.com, but not to other subdomains, such as mail.example.com.

The Storage Object

The following properties and methods are supported by both session and local storage objects.

...

TopicContents
clear

Removes all key/value pairs from the Web Storage area.

constructor

Returns a reference to the constructor of an object.

getItem

Retrieves the current value associated with the Web Storage key.

key

Retrieves the key at the specified index in the collection.

length

Retrieves the length of the key/value list.

remainingSpace

Retrieves the remaining memory space, in bytes, for the storage object.

removeItem

Deletes a key/value pair from the Web Storage collection.

setItem

Sets a key/value pair.

Web Storage Events

Internet Explorer fires events when data in a storage area is updated, so that information can synchronized between multiple instances of the browser or tabs.

The following events are supported:

onstorage

The onstorage event is fired in a document when a storage area changes.  All documents sharing the same session context, and those that are currently displaying a page from the same domain or subdomain where local storage is being committed, receive the event.  If the target document object is not currently active, Internet Explorer does not fire any events.

onstoragecommit

Internet Explorer uses XML files to store local storage. The onstoragecommit event fires when a local storage is written to disk.

...

Top-Level Browsing Context and Hostname

Access to the session storage area is restricted by the top-level browsing context.  In Internet Explorer, a new browsing context is created for every tab.  Script running in one top-level browsing context has no access to storage created in another.  Sites can add data to the session storage, and it will be accessible to  any page from that hostname opened in the same window. 

(warning) Note:  The port and protocol/scheme are not evaluated as a part of this check.

Origin Determines Storage Limits

Disk quota limits are imposed against the domain of the page that sets the value, rather than the domain where the value is being set. This prevents malicious scripts from using up the storage quota of a related domain. It also prevents such scripts from using random subdomains to store unrestricted amounts of data.

Storage size is calculated as the total length of all key names and values, and a single storage area can contain up to 10 million bytes. The remainingSpace property is used to determine the available storage space.

Clearing the Storage Areas

Session state is released as soon as the last window to reference that data is closed. However, users can clear storage areas at any time by selecting Delete Browsing History from the Tools menu in Internet Explorer, selecting the Cookies check box, and clicking OK. This clears session and local storage areas for all domains that are not in the Favorites folder and resets the storage quotas in the registry. Clear the Preserve Favorite Site Data check box to delete all storage areas, regardless of source.

To delete key/value pairs from a storage list, iterate over the collection with removeItem or use clear to remove all items at once. Keep in mind that changes to a local storage area are saved to disk asynchronously.

References

Further Reading

...