For more information on what merlyn said, see RFC 2965. You can restrict cookies by domain, server, path, port and to only HTTPS.

If you wish to share cookies between servers (even if they're physically the same system, but use different host names), you'll need to set the cookies in a domain that all of the hosts share. If you don't control all of the systems in your domain, you can place them in a subdomain (assuming you have access to DNS in your domain).

For example, I can take two systems, in domain.tld, and give each one a CNAME in shared.domain.tld, so I can then set cookies to be shared between the two systems in .shared.domain.tld (note the initial period). Of course, if someone follows a link that does not refer to the machines as being in the shared subdomain, the cookies won't be sent from the browser. (which can be useful to set both shared and unshared cookies, but you can mess it up very, very easily, if you're not careful.

I think you want to look at the raw_cookie() method in CGI and the stuff in CGI::Cookie. In its documentation, you'll discover that it returns the value of whatever is in the HTTP_COOKIE environment variable. The value is set by the web server when it parses the request.

It's your browser which decides which cookies to add to the request though.

As has been pointed out, any sane web browser only sends cookies for the appropriate domain. This is a measure to protect the user's privacy.

However, there is no protection for the server from seeing fake data. Just like query parameters (or anything else in the HTTP request) a mischievous user can send whatever he wants to your CGI. NEVER trust anything you get from a remote user.

A session cookie should therefore either only contain a random number that maps to something in your database, or be cryptographically signed (for example with a keyed hash function). Relying on a userid or nickname sent via cookie is asking for abuse.