You can't set and retrieve a cookie in one request. By the time you send the cookie to the browser, the browser has already finished sending information to the server — it's not going to turn around and send the cookie right back. That's not how HTTP works.

Depending on your browser, you may have to set a domain and a path in the cookie as well.

The server requests that a cookie be set - Your server application has no control over whether a cookie has been set. Your app will only know when the user requests the next page. Features such as session tracking can be handled using non-cookie means such as URL re-writing.

The browser makes the rules - Your app can only request that a cookie be stored. It is up to the browser settings (as dictated by the user, sys policy etc.) whether to cooperate with a set-cookie request. The decision depends on the security and privacy settings implemented by the browser.

The rules are changing - It used to be the case that browsers had a config option to turn cookies on or off. Then there came 'security zones' which divided the network up into internet, intranet and trusted zones. A different cookie policy could be enforced for all. Now the cookie settings are more associated with privacy and things such as third-party cookies and cookies that contain identifiable information are normally turned off. A new feature is the P3P policy of a server. This is a method that the site owners have of declaring their cookie usage policy such that it can be enforced by the browser.

Bug Fixing

• Cookies are limited in size. Try and store anything larger than 4kb per cookie and expect not to see it again (or if you do it may be truncated).
• The number of cookie per site is limited. They are cleaned out on an oldest loses basis. This is to stop a website from filling up your hard disk. You can fall foul of this problem if your site is a portal and there are a number of applications that want to set cookies using the same portal URL. Setting cookies that incorporate a path element is useful.
• You may not get back what you were expecting. A conflict between cookies set at the domain level and those set at the host level can leave you with the wrong cookies. I ran into this with java session IDs (all called JSESSIONID) being set by a number of different web app servers in the same domain. The browser will send what it thinks is the best cookie based on domain, host and path matching.
• Cookies can get lost in transit if any part of the cookie handling mechanism doesn't work. I was loosing cookies because a web server filter had a fixed buffer size for HTTP header handling. When you debug you need to confirm that the cookies are being sent and retrieved at different stages in the pipeline.
• There are cookie related issues that affect one browser and not another. Mozilla will work OK with cookies from a host name that contains an embedded underscore; IE6 will not. Check that your application works with different browsers and browser versions.

I find that working with Mozilla gives me the flexibility that I need when debugging cookie related issues. Just set your preferences to 'always ask' about cookies so that you can watch the cookie setting process. There is also an addin that allows you to watch the HTTP headers (I forget what it's called but I am sure that another monk will help out).

I find that working with Mozilla gives me the flexibility that I need when debugging cookie related issues. Just set your preferences to 'always ask' about cookies so that you can watch the cookie setting process. There is also an addin that allows you to watch the HTTP headers (I forget what it's called but I am sure that another monk will help out).

it's called live HTTP headers and it rocks.

anders pearson

Besides Live HTTP Headers there is also a nice extension called Web Developer, which has a "Cookie information" function that will show you *tada* Cookie information. Might be helpful here too.

--
b10m

All code is usually tested, but rarely trusted.

I just copy/pasted your script into a new page, and uploaded it to my webserver. The first time it loaded, it said "Can't find the cookie!". When I reloaded, it said "Nikolas". It'll keep doing that until I close my browser, I'm sure.

Update: So it does.

Anyway, don't listen to other people saying you can't read and set a cookie in one script. You can, and apparently, as in your script, even in reversed order.

don't listen to other people saying you can't read and set a cookie in one script

Who said that? I said you can't set and read a cookie in the same request. As far as I can tell, that remains true.

yes actually now that i have tried it again it worked for me too! :) But this cookie will se to each visitor right? how can it identify me from others?

Ah, that problem again. <grin>

Well, I can think of basically two approaches. Either you provide a special, different cookie value to each user, either semi-randomly assigned or via a login page, and you can then track any visitor to your site.

Or, you don't set cookies for everybody, but only for yourself. You can have a special page, which you use to enter the site, but which nobody else knows of. All it has to do is set a cookie, and redirect you to the normal entrance. Every other page only has to read the cookie value. The following code forms the entrance page for the latter approach:

#!/usr/bin/perl -w
use CGI qw(:standard);

my $cookie_out = cookie(-name=>'test', -value=>'Nikolas was here!');

print redirect(-cookie=>$cookie_out, -uri => "index.html");
[download]

I'm assuming "index.html" is the normal index page to your site's directory.

Now if you change the other script so it only reads the cookie (so drop the assignment to $cookie_out), you can visit the above script first, then go to the other script, possibly even by typing in the URL manually, and you'll see the cookie value as set here.

To identify 'you from others' you will need to store a bit of info. Traditionally you will generate a unique session ID for a user that allows you to map that unique session ID to any data you want. You usually just store the session ID in the cookie and store the data on the server in some sort of persistent store - you have MySQL so that is as good as anything. This is one way to maintain state across the stateless HTTP protocol. Super search for 'session management' or similar to see lots of examples.

CGI::Session may be what you are looking for.

cheers

tachyon