In the modern world of fawningly friendly e-retailing, cookies play an essential role in allowing web sites to recognize previous users and to greet them like long-lost, rich, childless uncles. Cookies offer the webmaster a way of remembering her visitors. The cookie is a bit of text, often containing a unique ID number, that is contained in the HTTP header. You can get Apache to concoct and send it automatically, but it is not very hard to do it yourself, and then you have more control over what is happening. You can also get Perl modules to help: CGI.pm and CGI::Cookie. But, as before, we think it is better to start as close as you can to the raw material.
The client’s browser keeps a list of cookies and web sites. When the user goes back to a web site, the browser will automatically return the cookie, provided it hasn’t expired. If a cookie does not arrive in the header, you, as webmaster, might like to assume that this is a first visit. If there is a cookie, you can tie up the site name and ID number in the cookie with any data you stored the last time someone visited you from that browser. For instance, when we visit Amazon, a cozy message appears: “Welcome back Peter — or Ben — Laurie,” because the Amazon system recognizes the cookie that came with our HTTP request because our browser looked up the cookie Amazon sent us last time we visited.
A cookie is a text string. It’s minimum content is Name=Value, and these can be anything you like, except semicolon, comma, or whitespace. If you absolutely must have these characters, use URL encoding (described earlier as “&” = “%26”, etc.). A useful sort of cookie would be something like this:
Butterthlies=8335562231
Butterthlies identifies the web site that issued
it — necessary on a server that hosts many sites.
8335562231 is the ID number assigned to this
visitor on his last visit. To prevent hackers upsetting your dignity
by inventing cookies that turn out to belong to other customers, you
need to generate a rather large random number from an unguessable
seed,[3]
or protect them cryptographically.
These are other possible fields in a cookie:
expires=
DATE
The word expires introduces a date and time after
which the browser will forget the cookie. If this field is absent,
the cookie is forgotten by the browser at the end of the session. The
format is: Mon, 27-Apr-2020 13:46:11 GMT.
“GMT” is the only valid time zone.
If you want it to be “permanent,”
select a date well into the future. There are, however some problems
with different versions of Netscape. The summary that appears in the
Apache documentation reads:
Mozilla 3.x and up understands two-digit dates up until “37” (2037). Mozilla 4.x understands up until at least “50” (2050) in 2-digit form, but also understands 4-digit years, which can probably reach up until 9999. Your best bet for sending a long-life cookie is to send it for some time late in the year “37”.
domain=
DOMAIN_NAME
The browser tail-matches the DOMAIN_NAME
against the URL of the server. Tail-matching
means that a URL shipping.crate.acme.com matches acme.com,and it makes sense when you
remember that the URL tree works from the right: first the .com, then
acme, then crate...
path=
PATH
If the domain matches, then the path is matched, but this time from
the left. / matches any path,
/foo matches /foobar and
/foo/html.
secure
This means that the cookie will only be sent over a secure channel, which, at the moment, means SSL, as described in Chapter 11.
The fields are separated by semicolons, thus:
Butterthlies=8335562231; expires=Mon, 27-Apr-2020 13:46:11 GMT
An incoming cookie appears in the Perl variable
$ENV{'HTTP_COOKIE'}. If you are using
CGI.pm, you can get it dissected automatically;
otherwise, you need to take it apart using the usual Perl tools,
identify the user and do whatever you want to do to it.
To send a cookie, you write it into the HTTP header, with the prefix
Set-Cookie:
Set-Cookie: Butterthlies=8335562231;expires=Mon, 27-Apr-2020 13:46:11 GMT
And don’t forget the terminating
\n, which completes the HTTP headers.
It has to be said that some people object to cookies — but do they mind if the bartender recognizes them and pours a Bud when they go for a beer? Some sites find it worthwhile to announce in their Privacy Statement that they don’t use them.
[3] See Larry Wall, Jon Orwant, and Tom Christiansen’s Programming Perl (O’Reilly, 2000): “srand” p. 224.