Re: Cookie Tutorial

Cookies are a pain in the rear, and fairly horribly documented. a few "features" that you will want to note:

Cookies are placed in the header of a page. This means that the page that sets the cookie (for example, the page displayed after a login) will NOT have access to the cookie. Now, since that page is setting the cookie, it knows the information, but don't expect to be able to read it from the cookie. (For a demonstration of this, Try logging into PerlMonks, but refuse all cookies. At first it will appear that it worked, as the login page displays your login name, but later pages will not show you logged in, because they are looking for the cookie)
Most browsers stop cookie processing as soon as they hit a cookie they don't like (written wrong, for the wrong domain, whatever). There is no indication when this happens, (except that later cookies aren't set)
The CGI.pm documentation says in one place that PATH defaults to the script, and in another it says it defaults to blank (anywhere on the server). IIRC, it actually defaults to the script, which means that for a site-wide cookie, you'll need to set that.
Turn remove a cookie, set the EXPIRES date to either "NOW" (I think) or some date in the past (I always use -3M )

I heavily recommend you turn on whatever "Confirm cookies" option your browser uses, and experiment. One major headache with cookies is that they don't appear in View Source, so running your script from the command line or telnetting to port 80 to try it out might be helpful.

Comment on Re: Cookie Tutorial

Replies are listed 'Best First'.
RE: Re: Cookie Tutorial by BBQ (Deacon) on May 31, 2000 at 05:14 UTC
I'm sorry to disagree. Everything you noted above is true, although I don't think the documentation is bad! Scarce maybe, but the articles and books that I've found did a good job of explaining the mechanics of a cookie and what the browsers don't do (but should). The one thing you forgot to mention is that when you set a cookie's host, you MUST access the host using the same name. Ie: http://foo/ ne http://foo.bar.com/ I started using cookies with cookie-lib.pl which is a cookie library (doh!) inspired by cgi-lib.pl. That was a mistake! Many of the odd features that I blamed cookies and browsers for ended up being faulty implementations on the lib I was using. Once you fully understand the consequences of keeping user state (since HTTP still is a stateless protocol) through cookies, you can plan ahead, test, re-test and make sure that your applications run smooth. Without cookies, my coding would soon become a living nightmare. cookies++ !! UPDATED: BTW: You can always inspect your cookies by doing something in the lines of: `# this line is from perldoc my $c = new CGI::Cookie(-name => 'foo', -value => ['bar','baz'], -expires => '+3M'); print "Set-Cookie: $c\n"; print "Content-Type: text/html\n\n"; print "<!-- inspect your cookie $c -->\n"; #etc...` [download] ... and that would keep you from having to telnet to port 80 to retract your cookie info. (make sure to remove the comment line on production code, it looks odd) #!/home/bbq/bin/perl # Trust no1!	[reply] [d/l]

Replies are listed 'Best First'.

RE: Re: Cookie Tutorial
by BBQ (Deacon) on May 31, 2000 at 05:14 UTC

odd features

UPDATED:

# this line is from perldoc
my $c = new CGI::Cookie(-name    =>  'foo',
                        -value   =>  ['bar','baz'],
                        -expires =>  '+3M');
print "Set-Cookie: $c\n";
print "Content-Type: text/html\n\n";
print "<!-- inspect your cookie $c -->\n";
#etc...
[download]

make sure to remove the comment line on production code, it looks odd

#!/home/bbq/bin/perl
# Trust no1!

[reply]
[d/l]

In Section Seekers of Perl Wisdom