Cookies go in the header, not after the header. After the \r\n\r\n sequence, it's for the browser to display, not interpret.

print $q->header( -cookie => [ $cookie, $cookie2 ] );
[download]

Putting the cookie after the header was a means for me to see what the actual Set-cookie: header would look like, since I don't have shell access to this server.

The point you make really has nothing to do with why the cookie itself is being written entirely incorrectly, so incorrectly, that my browser won't even accept the cookie.

I understand how to use the CGI and the CGI::Cookie modules, I just haven't a clue why both of these modules are mucking up so badly

 

-justin simoni
!skazat!

I think he's right. Try it. CGI::Cookie uses some tricky stuff to make the print $cookie possible and it may get messed up after you call the header method. You can debug the headers by using GET -ed http://yourserver.com/ to dump them out. GET is a script that comes with LWP, which you should install if you don't already have it.

Putting the cookie after the header was a means for me to see what the actual Set-cookie: header would look like, since I don't have shell access to this server.

In that case, change   print $cookie; to   print $cookie->as_string();

I haven't found the CHANGES or BUGS file associated with these modules, because I believe they're both bundled with Perl itself.

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.

Have you tried the latest CGI.pm? The latest is CGI.pm-2.91. I suggest you try it out and report back.

I was hoping for a better explaination than just to try a newer version. It's odd (in my example) that the older version doesn't have this bug, yet the newer one does. The fact of the matter is that this version of CGI.pm is in the wild and ithe problem is being addressed to me in alarmingly higher frequencies each week.

but since CGI.pm is distributed CPAN, it doesn't matter.

It does matter, since the CGI.pm module is one of the most widely used modules out there. This makes it sensitive to changes.

I did find a changelog here, The only mention of cookie bugs fixed (or at all) is for version 2.29, the problem server is running 2.57.

The problem I'm facing is that this is for a freely distributed, Open Source program and asking people to either upgrade their Perl, CGI.pm, or,install and import from a different version of a CGI.pm is over many of the user's heads.

 

-justin simoni
!skazat!

OK, here is the version of your script I placed on a Sun Solaris web server:



#!/usr/bin/perl -w
use strict;

use CGI qw(:standard);
use CGI::Cookie;
my $q = new CGI;

my $cookie =   $q->cookie(-name  =>  "CUSTOMER1",
                          -value =>  "WILE E. COYOTE",
                          -Path  =>  "/");

my $cookie2 =  new CGI::Cookie(-name  =>  "CUSTOMER2",
                               -value =>  "BEEP BEEP",
                               -Path  =>  "/");

print $q->header;
print $cookie;
print "<br>\n"; # $q->br;
print $cookie2;
print "<br>\n"; # $q->br;
[download]

(Note: we are using 2.42, the br method is not supported.)

When I run this from a shell command line I get:

Content-Type: text/html

CUSTOMER1=WILE%20E.%20COYOTE; path=/<br>
CUSTOMER2=BEEP%20BEEP; path=/<br>
[download]

When I invoke this via a browser, it displays:

CUSTOMER1=WILE%20E.%20COYOTE; path=/
CUSTOMER2=BEEP%20BEEP; path=/
[download]

This is in keeping with behavior I would expect.

I am not clear on what it is you are trying to do with this script in the first place. If you are trying to see the actual ASC string that the browser uses to set a cookie, this is the wrong way to do it.

Regardless of which method you are using to create a cookie, all you are doing is creating a reference to a hash with the values needed to make a browser set the cookie when it gets it. This does not include the cookie header or the way the values must be formatted for the browser to handle them properly.

To make a browser set a cookie, you always have to issue the Set-cookie: header prior to the first Content-type: header sent to the browser. Using CGI.pm, this is accomplished by passing the cookies to the header method. If you replace all the print statements in your script with



print $q->header(-cookie => [$cookie, $cookie2]);
print "Hello there!<br>\n";
[download]

then the browser will set the cookies properly (and you won't be issuing an empty HTML document either, as your example does).

For further information on cookies, see: http://wp.netscape.com/newsref/std/cookie_spec.html.

Note that you can bypass CGI.pm altogether and make a CGI script send what the browser needs to set a cookie and display some HTML this way:

#!/usr/bin/perl

print <<EOF;
Set-cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-
+03 23:12:40 GMT

Content-type:text/html

<html><body>
Here is some HTML blather.
</body></html>
EOF

exit(0);
[download]

-