I'm pretty sure the cookie must be set before the content-type header, otherwise it will print at the top of your output. :-)
print "Set-Cookie: chocolate=chip; path=/; expires Sunday, 30-May-2008 18:00:00 GMT\n";
Note SINGLE newline.
print "Content-type: text/html\n\n";
The double newline flushes the headers and begins output - so digitalghost's example may be perfectly valid. I'm just not used to doing it that way.
The above is what's called a persistent cookie. This is the type of cookie you're finding in your browser cookie jar. It is only persistent because it is in the full cookie format, including a VALID expiration date (believe me, that one can be a slippery character . . . )
Not to bear bad news - which it really isn't - but if the number of cookies being set by web sites bothers you, you might cringe and the number of non-persistent cookies that are being set that don't get stored (permanently, or until expire) in the jar:
print "Set-Cookie: chocolate=chip; path=/;\n";
A non-persistent cookie is a session cookie that expires as soon as the browser is closed. I love using this one - no mess, no fuss, but it precludes using it in an "auto log me in" or "save visitor settings" scheme.
I read that exact same document and man, I have to say, I could see about 100 points at which the "facts" can lead to paranoia for the general public. This means "COOKIES=BAD=DISABLE!" which makes my job soooo much more difficult.
What people don't seem to understand is the power of cookies is limited. While I'm sure there are some nefarious tactics by which they can be abused, for the most part, cookies are relatively harmless.
I think the most important thing for the average user to know about cookies is A cookie can only be set and get by the same domain. So if site A sets a cookie, site B cannot read it. This negates the largest paranoia of cookies, that they can unanimously "track user movements." *SEE EXCEPTION
An example where this is painfully obvious: you drop items into a shopping cart on http//yourdomain.com. The cookie sets a number to hook you up with your list of widgets stored in the database. When you go to checkout, which is now https//yourdomain.com, the non-SSL cookie cannot be read because you're on a new domain. So as a programmer you must send some token via post or get to re-set a new cookie on THAT domain to keep the two connected. This allows you to browse back and forth from SSL to non-SSL without a) losing track of your cart, or b) putting the entire site on https (the programmers for some sites apparently can't figure this out and actually do this.)
IMO people worry too much about cookies. I used to, until I realized their limitation and how useful they are. Far outweighs the bad.
*EXCEPTION: I do believe FireFox only accepts first party cookies, as described above (am I wrong anyone?) Internet Destroyer, however, will accept third party cookies, which is an opening for the thing everyone fears: tracking Internet movements.
Why IE does this or allows it I'll never know. My settings for IE are always "accept first party cookies" and "block third party cookies."