in reply to using cookies with UserAgent

I ran into the same problem using CGI.pm's cookie tricks. Here's what I discovered it (as I remember it): I was setting and retrieving the cookie correctly, the problem was that the cookie hadn't appeared in the environment before I tried to retrieve it, because the page that followed the redirect hadn't had it's headers sent yet, which contained the cookie. I saw a good solution to this in Justin Simoni's code (which I haven't tested yet.). He used the CGI.pm 'redirect' function, which can include attributes for both 'location' and 'cookie'. Before I found that, I was using a cheesy hack of printing a page with a meta tag refresh instead of redirecting directly. This insured that the cookie appeared in the environment before I tried to retrieve it again. Good luck! -mark
  • Comment on redirecting directly after setting a cookie

Replies are listed 'Best First'.
RE: redirecting directly after setting a cookie
by isotope (Deacon) on Oct 05, 2000 at 04:10 UTC
    There's nothing wrong with a good old refresh... just remember that the META tag is a way to insert data that should be treated as a header when you don't have the capability to insert a true header. Since you're writing CGI scripts, just add a real Refresh header that looks something like this:
    my $refresh_header = "Refresh: 0; URL=http://example.com/nextpage.cgi\
+n";

    [download]
    This is perfectly correct and results in a new request with a particular delay. Unlike a traditional redirect, most browsers will *not* attempt to rePOST data (which they technically shouldn't do anyway, IIRC).

    That's not the problem the poster is having, though. He's writing a client.

    --isotope
[reply]
[d/l]

In Section Seekers of Perl Wisdom