Test of cookies accepted or rejected?

[rlingen]

I have been using Matt Liebson's cookie.lib for all my (limited) cookie work. It has been working fine, but for one application, I need to know whether the cookie was accepted before I go on. My algorithm looks like this:

if(cookie already exists)
do stuff

else #set a cookie

If the client's browser is set to reject cookies, there is no error message, and the script goes merrily along, except that any variables that depended on the cookie's contents end up with null values.

I tried extending the algorithm to test for the cookie's existence immediately after setting it, figuring this would let me know whether it was successfully set. i.e.

if(cookie already exists)
do stuff

else #set a cookie

get the cookie
if(successfully got the cookie)
everything is fine
else
print an error message about need to have cookies enabled

this all works fine if the cookie already exists. However, whether or not cookies are enabled, it always goes to the error message the first time, even though the cookie ends up getting set just fine. (Subsequent calls to the script find the cookie ok). I think what is happening is that the call to get the cookie (to check for its existence) is coming too quickly after setting it.

Is there a better way to check to see if the cookie was accepted before progressing? Do I just need some changes to this algorithm? Any solution must take care of the situation where a user has set his browser to warn of cookies and accepting them individually.

This script must run on a number of different servers, so I do not want to rely on having a specific module available - I'd rather use a library.

I look forward to any advice.

Roy

 

[abraxas]

Giday Roy,
I looked at your question two weeks ago and noticed the lack of response to it which (now) I can understand. I was compelled to examine the use of cookies with HTTP headers since this was my first time dealing with this kind of programming philosophies. May I suggest RFC2109 if you have not already for enlightenment. Whatever runs hotmail now hasn't. Try disabling cookies in whatever browser and see how far you get.
GET + SET - Yes in one header
SET + GET - No in one header (ie refresh needed)

The only work around I could come up with involves a javascript perl combo so this depends if the perl script is called by html (or something else) eg shopping cart rubbish which is the predominant usage for them. In this case, to make the process absolutely bullet-proof a javascript which is called by the addtocart feature.pl <input type=whatever onclick(call script)> and loaded in the referer html helps heaps. This can set up cookie verification and offer alert() boxes to return control to the html before it reaches inocent CGI . But it can also set a unique cookie (anything so long as it is the same for everyone who connects) such as uniqueID=343434hj3h4434hh for a session only and one that your perl script can test for since it knows that particular string and if it's there for this session , if (&GetCookie('uniqueID') { returns 1, then your script is assured of cookie support. Add REQUEST_METHODs and HTTP_REFERER and their ilk and we are starting to look fashionable.

Straight forward js cookie scripts are available anywhere but bell me if you want something simple. Also in .js is the ability to pick up document.referer which can help a bit in html working out whom called it.

Hope this helps a bit but please tell me if you have found another workaraound.
abraxas