Contents:
An Overview of Cookies
Reading Cookies
Storing Cookies
Cookie Limitations
Cookie Example
The Document object contains property named cookie that was not discussed in Chapter 14, Documents and Their Contents. On the surface, this property appears to be a simple string value. Surface appearance to the contrary, however, the cookie property controls a very important feature of the web browser, and is important enough to warrant a complete chapter of its own.
A cookie is a small amount of named data stored by the web browser and associated with a particular web page or web site.[1] Cookies serve to give web browsers a "memory", so that they can use data that were input on one page in another page, or so they can recall user preferences or other state variables when the user leaves a page and returns. Cookies were originally designed for CGI programming, and at the lowest level are implemented as an extension to the HTTP protocol. Cookie data is automatically transmitted between web browser and web server so that CGI scripts on the server can read and write cookie values that are stored on the client. As we'll see later in this chapter, client-side JavaScript code can also read and write cookies with the Document.cookie property.
[1] The name "cookie" does not have a lot of significance, but is not used without precedent. In the obscure annals of computing history, the term "cookie" or "magic cookie" has been used to refer to a small chunk of data, particularly a chunk of privileged or secret data, akin to a password, that proves identity or permits access. Cookies as used in JavaScript are used to save state and can serve to establish a kind of "identity" for a web browser. Cookies in JavaScript do not use any kind of cryptography, and are not secure in any way.
Document.cookie is a string property that allows you to read, create, modify, and delete the cookie or cookies that apply to the current web page. It can allow you to do all this because the property does not behave like a normal read/write string property. You may both read and write the value of cookie, but setting the property has the side effect of creating a new cookie for the web page, while reading the property has the side effect of returning a list of all cookies that apply to the web page. Later sections of this chapter explain in detail how to read and write cookie values using the cookie property.
In order to use cookies effectively, however, you need to know more about them. First, cookies are transient by default--the values they store last for the duration of the web browser session, but are lost when the user exits the browser. If you want cookies to last beyond a single browsing session, then you specify an expiration date--this will cause the browser to save its cookies in a local file so that it can read them back in. In this case, the cookies values will be saved until the expiration date has past.
The second point that is important to understand about cookies is how they are associated with web pages. By default, a cookie is associated with, and accessible to, the web page that created it and any other web pages in the same directory, or subdirectories of that directory. Sometimes, though, you'll want to use cookie values throughout a multipage web site, regardless of which page creates the cookie. For instance, if the user enters their mailing address in a form on one page, you may want to save that address to use as the default the next time they return to the page, and also use it as the default in another form on another page where they are asked to enter a billing address. To allow this, you specify a path for the cookie. Then, any web pages from the same web server that contain that path in their URL will share the cookies. For example, if a cookie's path is set to "/acme", and this cookie is set by the page http://my.isp.com/acme/catalog/index.html, then the cookie will also be accessible to the page: http://my.isp.com/acme/order/ index.html. If no path were set in this example, then the default path would be "/acme/catalog", and the cookie would not be accessible from the "/acme/order" directory.
By default cookies are only accessible to pages on the same web server from which they were set. Large web sites may want cookies to be shared across multiple web servers, however. For example, the server at order.acme.com may need to read cookie values set from catalog.acme.com. This is possible if the cookie has a domain set. In this example, if the cookie has its domain set to acme.com, then it will be available to pages on both of the servers mentioned above, as long as those pages have URLs that match the cookie's path. When setting the domain of a cookie for use across multiple servers, you may often want to set a very generic path like "/". If no domain is set for a cookie, the default is the hostname of web server that serves the page. Note that you cannot set the domain of a cookie to a domain other than the domain of your server.
The third and final point to understand about cookies is that they can be secure or insecure. By default, cookies are insecure, which means that they will be transmitted over a normal, insecure, HTTP connection. If a cookie is marked secure, then it will only be transmitted when the browser and server are connected via HTTPS or another secure protocol.
See Appendix F, Persistent Client State: HTTP Cookies, for full technical details on cookies, including their expiration, path, and domain. That appendix contains the actual specification for HTTP cookies, and so contains low-level details that are more suitable to CGI programming than to JavaScript programming. The following sections discuss how you can set and query cookie values in JavaScript, and how you can specify the expiration, path, domain, and security level of a cookie.
This HTML Help has been published using the chm2web software. |