A workaround is to set the cookie with javascript. Javascript will allow you to set a cookie after the content header has already been sent (as in your case). So /cgi-bin/myscript.cgi could print the javascript html code setting the cookie/s you need.

Although this isn't perl, here's some javascript for setting a cookie. It's a function followed by the call. This script sets a cookie called myName to Bubba. You set the cookie just like you would in perl. Specifying all the cookie parameters you need. Again, this snippet is javascript, not perl.

function setCookie(name, value, expires, path, domain, secure) {
var curCookie = name + "=" + escape(value) +
((expires) ? "; expires=" + expires.toGMTString() : "") +
((path) ? "; path=" + path : "") +
((domain) ? "; domain=" + domain : "") +
((secure) ? "; secure" : "");
document.cookie = curCookie;
}
now=new Date();
now.setFullYear(now.getFullYear()+1);

setCookie("myName", "Bubba", now, "/" ,".yourdomain.com");
[download]

The only problem with using Javascript, though, is that more and more people have turned it off to prevent "browsing annoyances" (pop-up windows and the like), and also because of it opening a whole can of worms with respect to security.

Not only that, the implementation of Javascript differs from browser-to-browser (and even between different implementations of the same browser on different OSs), though I'm not sure that'd make any difference with what you have there. A good, high profile, example of this is the new Opodo website: it's written entirely in Javascript, and while it works perfectly in IE, it won't work in anything else.

I think that it's important to point out that a Javascript solution certainly won't work for everyone out there, whereas the original Perl solution to set the cookie probably would have.

-- Foxcub
#include www.liquidfusion.org.uk

Thank you both, for suggesting JavaScript and reminding me of its pitfalls.

I'm quite experienced with JS issues, in fact to my shame have coded a lot more JS than Perl.

The version of Best Practice at my work is that no site should require JS for navigation or function. That there should always be a fallback position.

This code, for instance:

<a href="#" onclick="somefunction()">

// not allowed. Leaves some users clicking in vain.
[download]

But this...

<a href="fallback.html" onclick="somefunction();return false;">

/* 

...is kosher. JS people get the function, non-JS people
get something else. A popup window for instance, might
navigate for the non JS user into a regular-sized page. It 
might look a little weird, but that's better than
inviting them to click and frustrating the hell out of 
them.
And the return false prevents JS people from calling both
the function and the regular click.

*/
[download]

In my case, the cookies serve the purpose of letting users know that a certain thing has been "updated since last visit".

As this is a bonus feature, rather than an essential one, it passes the test of something that may be implemented in JS, as long as, in the absence of JS, the user experience is not compromised in any way.
--


“Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.”
M-J D

-- Foxcub
#include www.liquidfusion.org.uk