mhh, you're printing the header inside a loop? usually, only the first run would actually produce a header, on the next iteration, the header had already been printed. Do you expect multiple cookies to be set?

i would try using a header checker such as Live HTTP Headers for FF and carefully examine the response for clues.

How do you do a live http header check. I didn't get to mess with this project much today but the progress is as wacky as the day is long--in Opera you can sign in and cookies are written, can go into Firefox and cookies are there and IE, well, it takes you to the page but not writing a cookie yet.
On the thing about working inside a loop--probably the wrong way to go about doing things but it has always worked for me for getting cookie info out of mysql. When I get back to work on this thing I'll try using selectrow array, i.e.,
($_[0], $dbvalue1,$dbvalue2) = $dbh->selectrow_array($query);
Praying for success. Thanx for all the info--you people here are the best--perl 4ever!

Install the Live HTTP Headers-Addon [addons.mozilla.org] for firefox, then Launch the viewer (Should be in the Tools-Menu after install & firefox restart) and surf your site where you expect to get cookies set. You will see the headers of the HTTP communication and can see what your script actually sent to firefox, and with that it'd also be much easier to help you diagnose what is going on.

BTW, just a shot in the dark: are you sending the cookies on a redirecting response? I've done that once and firefox did not accept my cookie until I've added an expiration date that is at least 2 hours from now.

Thanks janharders--I got the cookies writing in both Firefox and Opera now. Can't get them in IE though. Is there something like HTTP Headers for IE. The re-direct I'll be using is semi-manual-that is, after the cookie is written a sub routine will be called which will display a link on the screen with the word Continue and that goes to page with a redirect-that way the cookie info needed will be available. Only takes an extra click and its for an admin panel that I'll be the one mostly using so that's no problem-that is another project.

Also, I changed the method for getting the info from the database:

my($value1,$value2,$value3);
my $dbh = DBI->connect('connection paramaters') or die("Couldnt connect");
my $query = "select blah1,blah2,blah3" . " from table where binary column_name = '$_[0]' limit 1";
($value1,$value2,$value3) = $dbh->selectrow_array($query);
use CGI::Cookie;
my $query = new CGI;
my $cookie = $query->cookie(-name=>'oreo',
 -value=>"$value1|$value|$value3",
 -expires=>'',#when the browser closes
 -path=>'https://selected_url/');
print header(-cookie=>$cookie);

Any idea why this will write cookies in Opera and not IE or Firefox?

I got the cookies writing in both Firefox and Opera now. Can't get them in IE though.

the server should be sending the same headers, or at least the same cookies, regardless of browser type.
what did you change to fix it for firefox?

Is there something like HTTP Headers for IE.

which version of IE?
Using Windows Internet Explorer Developer Tools Network Capture (Internet Explorer):
http://msdn.microsoft.com/en-us/library/gg130952(v=vs.85).aspx [msdn.microsoft.com]
i'm not sure if this works for IE 8 or less or if there are add-on debug toolbars available for earlier versions of IE.
or perhaps use a tool like fiddler.

What do your values look like?
Also, you're sending


-path=>'https://selected_url/'

But Path should be a local URI, for the domain-part there is
-domain => 'www.example.com'

Maybe that's what IE doesn't like?

that would be ironic if IE actually followed protocol too closely.

There are 10 values total, 9 are only 1 character in length and the remaining one is 16 characters in length separated by pipes or a total of 19 characters(no spaces).

Confused on the comment about the path should be a local URI and if I try to enter -domain => 'www.example.com' into the script it won't write in any of the browsers if that's any clue . IE is nothing but problems, whether it be html, css, and now this.

what hostname are you serving from?
perhaps your domain should be specified at the root example.com

"local URI" means the path part of the URL to which the cookie applies.
the local URI starts with the slash after the hostname in the URL.

the path should be a local URI and if I try to enter -domain => 'www.example.com' into the script

Is that one command or two? All cookies use the domain and/or hostname (.example.com or www.example.com). The path is an optional extra for cookies that aren't for the whole site. Make sure you're not saying one when you mean the other.

:: grasping at straws ::
It's not reacting to the : in http: is it? I recently met a discussion of this issue in a completely different-- but cookie-related-- context.

I'm hosting through http://www.[hostingcompany].com/
I cleared the cache so no problem there.
I changed the path and the domain and getting the same results:

-domain=>'http://[hostingcompany].com';
-path=>'/home/users/web/username/public_html/cgi-bin/directory/');

Maybe I should make up a username&password and see if anyone else is getting the same results.

[edited by: tedster at 8:05 pm (utc) on Feb 19, 2013]
[edit reason] hosting specifics [/edit]

not your hosting company, but rather your hostname, which will be either your domain or a subdomain.
there is no protocol specified here - your hostname is going to look like example.com or www.example.com or subdomain.example.com but no http:.
the path is not usually the directory path from the root of the filesystem, but rather the url path from the document root directory for that virtual host.

if you want a cookie to work for all directories of your www. subdomain use:

-domain => 'www.example.com',
-path => '/',

if you want a cookie to work for the store subdirectory of all your domain's hostnames use:

-domain => '.example.com',
-path => '/store/',