and for reading it: <CODE> $mycgi->cookie(-name=>'sessionID'); <CODE>print $mycgi->header(-cookie=>$params->cookie(-name=>'sessionID', -value=>'some stuff', -expires=>'0', -path=>'/'));
CGI.pm's object interface really makes code cleaner. One assumes that the function oriented way you did it SHOULD work.
There are a bunch of other pitfalls with cookies though. One of the simplest ones to have is the "path problem". Netscape may not think it SHOULD return the cookie, because it may think its talking to a different web server.
In HTTP/1.1 the client sends a header that tells the web server what domain it is requesting a response from. The web server may be configured (IE apache "ServerName" directive) to return a response telling the browser the response came from a DIFFERENT domain, as in client asks for a page from www.rhombus.net, and apache (happily misconfigured) responds with an HTTP response telling the client the response came from barney.rhombus.net.
In that case your cookies WILL NOT WORK. Netscape or IE will figure that the cookie is intended for www.rhombus.net and the next time you ask for a page netscape will try to go to barney.rhombus.net, and so it won't send back the cookie, so no cookie value! Or alternatively your "path" parameter for the cookie may be specifying a domain that isn't the one apache is set up to respond as, results are the same.
In framesets this gets especially ugly. Browsers often don't seem to grok where content is really coming from. Telnetting to port 80 is highly useful sometimes...
In reply to RE: Fetching cookies.
by Anonymous Monk
in thread Fetching cookies.
by the_0ne
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |