Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: phranque
I have managed to figure out a way to have server side scripts transparently figure out if a browser has cookies enabled and am wondering if I could get input on any pitfalls to my approach.
It's a bit involved but here goes...
Under normal circumstances checking to see if a browser has cookies enabled cannot be done from the server side because although a cookie can be set when the user agent first requests a document, server side scripts must wait for the user agent to re-initiate a second HTTP request - before sending the cookie back. At which point a server side script can check to see if the cookie was enabled.
I noticed that stylesheets and graphics files cause a browser to automatically send HTTP requests for these files so...
I put the following in my HTML files...
<link rel="stylesheet" href="/general_stylesheet.css" type="text/css">
<link rel="stylesheet" href="/general.cde" type="text/css">
The /general.cde is not really a CSS file. It is a Perl script that checks to see if a cookie was accepted when it was first set by the script that outputs the HTML page in which the above is found. It also logs info into a custom log file of mine and performs other such background activities.
Along with the above I included the following in my apache httpd.conf file...
AddHandler cgi-script .cgi .pl .cde
which causes apache to execute any files ending in .cde as cgi scripts.
I had to fool the browser into loading my css "script" like it normally does CSS files so that it would be automatically requested.
I also included the following code in my general.cde script to keep this file from being cached by user agents and from returning an Apache status other than a 200 OK.
print "Expires: Thu, 29 Oct 1998 17:00:00 GMT\n";
print qq(Cache-control: no-cache="set-cookie")."\n";
print "Status: 200 OK\n";
Everything seems to be working just fine but I am wondering about the pros and cons of this approach. Will a search engine balk when it loads a suppossed CSS file that is not really a CSS file?
I also did not want to use a 1 pixel image - making it likewise a script - since I have heard that some SE's are frowning on 1px graphics. Making it bigger in pixels would have made it more apparent and less transparent. Also some surf with graphics off.
All in all my approach seems good but any input would be appreciated.
About the only downside to this that I can see might be the possibility that some older browser's might crash when trying to load and process a CSS file that is not really a CSS file. Also my relative URL used means I have to store a script in my document root instead of the CGI bin which might make it easier for hackers to break into it.
Lastly someone can just copy my HTML file, strip out the link line calling general.cde and defeat this whole mechanism though I doubt that most of my site visitors will not only look at the code and detect something fishy but also go to the trouble to strip out the link line.
About the only downside to this that I can see might be the possibility that some older browser's might crash when trying to load and process a CSS file that is not really a CSS file.
If you are concerned about this why not have your script return a real CSS file. The browser, in fact nobody, needs to know that the CSS file was created by a script. That is why the href attribute is defined as containing an URI, an resource identifier and not a file identifier.
RFC 2396 defining Uniform Resource Identifiers (URI): Generic Syntax [ietf.org] makes this quite clear:
A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources.
Under normal circumstances checking to see if a browser has cookies enabled cannot be done from the server side
What´s wrong with
setcookie('test', 'test');and testing whether you get the cookie back?
Thanks again for your input.
I tried using a "Location..." header (but in Perl) and the cookie was never returned. Perhaps partly because mod_rewrite directives in my .htaccess file took over and intercepted the redirection.
Or maybe not. I am not sure about why not but the cookie was not being returned. So I resorted to piggy backing on the fact that browsers automatically sent a new HTTP request for .CSS files.
Under normal circumstances I am not sure that the "Location" header forces a browser to re-load the page being relocated to and to send back the cookie. At least it didn't for me. I did get it to return a cookie by forcing a Status 301 header to be sent to the browser ahead of the Location header but unfortunately this messed up my mod_rewrites (in the sense that the Location URL started showing up in the browser address bar).
My site relies very heavily on mod_rewrite to "hide" the real names of files and scripts at my site and to redirect here and there internally. Among the more important advantages to this is that I can move my files anywhere I want in my directory structure without invalidating existing URL's.
Anyway things are working very well now.
Thanks again for your input Andreas (and to you too WebGuerilla).