Category Archives: Web Basics

Manipulating the browser history

and ) and provides functionality global to the document (such as obtaining the page’s URL and creating new elements in the document).” style=”margin: 0px; padding: 0px; border: 0px; color: rgb(0, 149, 221); text-decoration: none;”>document only if you modify only the hash.

  • You don’t have to change the URL if you don’t want to. In contrast, setting window.location = "#foo"; only creates a new history entry if the current hash isn’t #foo.
  • You can associate arbitrary data with your new history entry. With the hash-based approach, you need to encode all of the relevant data into a short string.

Note that pushState() never causes a hashchange event to be fired, even if the new URL differs from the old URL only in its hash.

The replaceState() method

history.replaceState() operates exactly like history.pushState() except that replaceState() modifies the current history entry instead of creating a new one.

replaceState() is particularly useful when you want to update the state object or URL of the current history entry in response to some user action.

Note: In Gecko 2.0 (Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1) through Gecko 5.0 (Firefox 5.0 / Thunderbird 5.0 / SeaMonkey 2.2), the passed object is serialized using JSON. Starting in Gecko 6.0 (Firefox 6.0 / Thunderbird 6.0 / SeaMonkey 2.3), the object is serialized using the structured clone algorithm. This allows a wider variety of objects to be safely passed.

The popstate event

A popstate event is dispatched to the window every time the active history entry changes. If the history entry being activated was created by a call topushState or affected by a call to replaceState, the popstate event’s state property contains a copy of the history entry’s state object.

See window.onpopstate for sample usage.

Reading the current state

When your page loads, it might have a non-null state object.  This can happen, for example, if the page sets a state object (using pushState() orreplaceState()) and then the user restarts her browser.  When your page reloads, the page will receive an onload event, but no popstate event.  However, if you read the history.state property, you’ll get back the state object you would have gotten if a popstate had fired.

You can read the state of the current history entry without waiting for a popstate event using the history.state property like this:

var currentState = history.state;


For a complete example of AJAX web site, please see: Ajax navigation example.

Browser compatibility

Feature Chrome Firefox (Gecko) Internet Explorer Opera Safari
replaceState, pushState 5 4.0 (2.0) 10 11.50 5.0
history.state 18 4.0 (2.0) 10 11.50 6.0


Session cookie


[edit]Persistent cookie


[edit]Secure cookie


[edit]HttpOnly cookie

The HttpOnly cookie is supported by most modern browsers.[17][18] On a supported browser, an HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript). This restriction mitigates but does not eliminate the threat of session cookie theft via cross-site scripting (XSS).[19] This feature applies only to session-management cookies, and not other browser cookies.


Third-party cookie




A “supercookie” is a cookie with an origin of a Top-Level Domain (TLD) or an effective Top-Level Domain. Some domains that are considered, “Top-Level” may in fact be a secondary or lower-level domain. For example, are considered Top-Level even though they are multiple levels deep. These domains are referred to as Public Suffixes and are not open for reservation by end-users.

Most browsers, by default, allow first-party cookies—a cookie with domain to be the same or sub-domain of the requesting host. For example, a user visiting can have a cookie set with domain http://www.example.comor A so-called “supercookie” is a cookie originating from a Public Suffix or Top-Level Domain such as, .com. It is important that these cookies are blocked by browsers otherwise, an attacker in control of malicious website with domain .com could set a “supercookie” and potentially disrupt or impersonate legitimate user requests to Thus taking advantage of the fact that .com can set valid cookies for sub-domain


[edit]Supercookie (other uses)

The term “supercookie” is sometimes used for tracking technologies that do not rely on HTTP cookies. Two such “supercookie” mechanisms were found on Microsoft websites: cookie syncing that respawned MUID cookies, and ETagcookies.[20] Due to media attention, Microsoft later disabled this code:

In response to recent attention on “supercookies” in the media, we wanted to share more detail on the immediate action we took to address this issue, as well as affirm our commitment to the privacy of our customers. According to researchers, including Jonathan Mayer at Stanford University, “supercookies” are capable of re-creating users’ cookies or other identifiers after people deleted regular cookies. Mr. Mayer identified Microsoft as one among others that had this code, and when he brought his findings to our attention we promptly investigated. We determined that the cookie behavior he observed was occurring under certain circumstances as a result of older code that was used only on our own sites, and was already scheduled to be discontinued. We accelerated this process and quickly disabled this code. At no time did this functionality cause Microsoft cookie identifiers or data associated with those identifiers to be shared outside of Microsoft.
—Mike Hintze[21]

[edit]Zombie cookie

Main articles: Zombie cookie and Evercookie
