04.11.2015 Views

javascript

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 19: Client - Side Storage<br />

❑<br />

❑<br />

❑<br />

Path — The path within the specified domain for which the cookie should be sent to the server.<br />

For example, you can specify that the cookie only be accessible from http://www.wrox.com/<br />

books/ so pages at http://www.wrox.com won ’ t send the cookie information, even though the<br />

request comes from the same domain.<br />

Expiration — A timestamp indicating when the cookie should be deleted (that is, when it should<br />

stop being sent to the server). By default, all cookies are deleted when the browser session ends;<br />

however, it is possible to set another time for the deletion. This value is set as a date in GMT<br />

format (Wdy, DD - Mon - YYYY HH:MM:SS GMT) and specifies an exact time when the cookie<br />

should be deleted. Because of this, a cookie can remain on a user ’ s machine even after the<br />

browser is closed. Cookies can be deleted immediately by setting an expiration date that has<br />

already occurred.<br />

Secure flag — When specified, the cookie information is sent to the server only if an SSL<br />

connection is used. For instance, requests to https://www.wrox.com should send cookie<br />

information, whereas requests to http://www.wrox.com should not.<br />

Each piece of information is specified as part of the Set - Cookie header using a semicolon - space<br />

combination to separate each section, as shown in the following example:<br />

HTTP/1.1 200 OK<br />

Content-type: text/html<br />

Set-Cookie: name=value; expires=Mon, 22-Jan-07 07:10:24 GMT; domain=.wrox.com<br />

Other-header: other-header-value<br />

This header specifies a cookie called “ name ” that expires on Monday, January 22, 2007, at 7:10:24 GMT<br />

and is valid for www.wrox.com as well as any other subdomains of wrox.com such as p2p.wrox.com .<br />

The secure flag is the only part of a cookie that is not a name - value pair; the word “ secure ” is simply<br />

included. Consider the following example:<br />

HTTP/1.1 200 OK<br />

Content-type: text/html<br />

Set-Cookie: name=value; domain=.wrox.com; path=/; secure<br />

Other-header: other-header-value<br />

Here, a cookie is created that is valid for all subdomains of wrox.com and all pages on that domain<br />

(as specified by the path argument). This cookie can only be transmitted over an SSL connection<br />

because the secure flag is included.<br />

It ’ s important to note that the domain, path, expiration date, and secure flag are indications to the<br />

browser as to when the cookie should be sent with a request. These arguments are not actually sent as<br />

part of the cookie information to the server; only the name - value pairs are sent.<br />

Cookies in JavaScript<br />

Dealing with cookies in JavaScript is a little complicated because of a notoriously poor interface, the<br />

BOM ’ s document.cookie property. This property is unique in that it behaves very differently<br />

depending on how it is used. When used to retrieve the property value, document.cookie returns a<br />

619

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!