|
|
|
|
|
|
|
|
|
|
|
|
|
|
ASP ADVANCED
Few
Internet technologies create greater agitation among Web users than cookies.
Cookies have an innocent-sounding name, but many users assume
that they have an evil purpose. Netscape
introduced cookies into the world with the first version of its browser.
Since then, the World Wide Web Consortium has endorsed a cookie
standard. Most browsers now
have the ability to use cookies. What
are cookies? Browsers that
support cookies maintain one or more special files.
These files, called cookie files on Windows machines and magic
cookie files on the Macintosh, are used to store data from Web sites.
A Web server can insert pieces of information into these cookie
files. This explains the
strong negative reaction some Web users have toward cookies.
Some people consider a cookie an invasion of privacy.
Even worse, some people consider cookies an invasion of their
personal space. Certain
cookies are temporary; others are persistent.
For example, the cookies used by Active Server Pages to track user
sessions expire after a visitor leaves the Web site.
Other cookies can remain in the cookie files to be read by the
server when a user returns. It's the cookies that remain in the cookie files that generate the most concern. The fear is that these cookies can be used to track an individual's Web surfing habits. The worry is that if this information falls into the wrong hands, the individual could become the target of multiple bulk mail advertising campaigns (a fate worse than death). However, this fear is completely unfounded. One Web server can't read another Web server's cookies. Cookies are implemented in such a way that this is impossible. Nevertheless, this misperception is so widespread that browser manufacturers have had no choice but to respond to it. Recent
versions of both Microsoft Internet Explorer and Netscape Navigator have
additional options that allow greater control over cookies.
You can configure either browser to warn you before accepting a
cookie. Additionally,
Netscape Navigator includes the option of disabling cookies entirely.
(Early beta versions of Internet Explorer 3.0 also had this option, but
then Microsoft came out with Active Server Pages and this feature
disappeared before the final release.) Moreover,
various ingenious techniques have been developed to disable cookies even
on the browsers that don't provide these options.
For example, you can disable cookies on a browser by making the
cookie files read-only (See http:///www.Cookiecentral. com).
Unfortunately,
the current state of affairs means that you can't depend on cookies when
building your Web site. Cookies
work on the majority of browsers, but fail completely when used with
certain browsers, and this means that sessions will fail as well. How
Cookies Work Cookies
are passed back and forth between a browser and server through HTTP
headers. The server first
creates a cookie by using the Set-Cookie header in a response.
Subsequent requests from the browser will return this cookie in the
Cookie header. Suppose
you want to create a cookie named UserName that contains the name of the
visitor to your Web site. To
create this cookie, the server would send a header like this: Set-Cookie:
UserName=BILL+Gates; path=/; domain=aspsite.com; This
header instructs the browser to add an entry to its cookie file.
The browser adds the cookie named UserName with the value Bill
Gates. Notice that the value
of the cookie is URLencoded. Furthermore,
the header informs the browser that this cookie should be returned to the
server regardless of the path used in the request.
If the path attribute were set to another value such as / private,
the cookie would only be returned in requests to this path.
For example, the request for the file /private/mypage.htm would
include the Cookie header but not the request/mypage.htm. The
domain attribute further restricts where the cookie can be sent by the
browser. In this example, the
cookie can be sent only to the www.aspsite.com Web site.
The cookie will never be sent to www.yahoo.com or any other Web
site on the Internet. Finally,
the Expires attribute specifies when the cookie should expire.
The header in the example tells the browser to store the cookie
until the first second of January 1, 1999.
Actually, the cookie will probably expire much earlier than that.
When a cookie file becomes too large, the browser automatically
starts removing cookies. Once
the browser has created a cookie, the browser returns the cookie in every
request it makes to the Web site--that is, every request that satisfies
the path requirement. However,
the browser won't send the cookie in requests to a Web site with a
different domain name. The
browser continues to send the cookie until the cookie expires.
The Cookie header looks like this: Cookie:
UserName: Bill+Gates Creating
and Reading Cookies with Active Server Pages To
create a cookie with Active Server Pages, you use the Cookies.collection
of the Response object. You
can create two types of cookies: a cookie with a single value, or a cookie
dictionary, which contains multiple name and value pairs. To
create a cookie with a single value, you can use a script like this: <% This
script creates a cookie named UserName with the value "Bill
Gates". This cookie will be returned by a user's browser until
January 1, 1999 or until the browser erases it.
If you don't specify an expiration date for the cookie, the cookie
expires when the user leaves your Web site. Because the example script actually creates a header, you must place the script before any out put statements in your Active Server Pages file. Alternatively, you can buffer the page (see the section "Buffering Output"). The
preceding script is a simple example of how you can create a cookie.
The example uses only the Expires attribute of the Cookies
collection. However, the
Cookies collection has a number of additional attributes.
Here's a more complicated example: <% This
script also creates a cookie named username.
However, this cookie has three additional attributes:
To
read a cookie within an Active Server Page, you use the Cookies collection
of the Request object. For
example, to output the
value of a cookie, you can use the following script: <%=Request.Cookies("UserName")
%> This
script outputs the value of the cookie named UserName.
As in all the collections discussed previously, you can use the
count attribute to determine the number of items in the Cookies
collection. You can also use
either a FOR ... EACH or a FOR... NEXT loop to iterate through the items
in the Cookies collection. This
example uses a FOR... EACH loop: <% Creating
More Than One Cookie You
can create more than one cookie, by simply creating multiple cookies with
the Response.Cookies collection as in the previous examples.
However, many browsers only support three or four cookies from a
particular Web site. An
alternative method is available for creating multiple cookies.
You can create a cookie dictionary.
A cookie dictionary is actually a single cookie with multiple
name-and-value pairs. Following
is an example of how you can create a cookie dictionary: <%
This
script creates a cookie dictionary with the name user and the keys
Name and Password. Set-Cookie:User=Name=Bill+Gates&Password=billions
A
cookie named user is created. However,
the value of user is actually two name-and-value To
retrieve a cookie dictionary, you can use the Request.Cookies collection
as in the preceding example. If
you simply provide the name of the cookie dictionary, the cookie
dictionary is returned in unparsed form.
To retrieve particular keys of the cookie dictionary, you pass the
name of the key to the collection. Here's
an example: <%=Request.Cookies("User)%> To
determine whether a cookie is a cookie dictionary, use the HasKeys
attribute. For example,
the following script returns True if the cookie is a cookie dictionary and
False otherwise: <%=Request.Cookies('User").HasKeys
%>
|
 |
||||
|
|
||||||
|
|
||||||
|
|
|
|
 |
