 |
| Web News |
UK broadband to soar in 2008
The Internet Service Providers' Association (ISPA) is forecasting healthy growth rates for IPTV, VoIP and video conferencing services over the coming year. Increased demand from UK users for high-quality...
Plan to give every child internet access at home
Parents could be required to provide their children with high-speed internet access under plans being drawn up by ministers in partnership with some of the...
Home computing pioneer honoured
One of the designers of the classic BBC Micro computer has been recognised in the New Year Honours list. Steve Furber, of the University of Manchester, was made a Commander of the Order of the British Empire (CBE).
Bebo crowned the best networking site
Bebo, the popular website aimed chiefly at teenagers, has been named the best performing social networking forum by experts who praised its efforts to enhance security and protect younger users from data theft...
Pensioners' Saga Zone rivals Facebook, Bebo
Silver surfers are behind one of the surprise hits of the internet, with a social networking site set up by Saga scoring top marks in a new report. Saga Zone, specifically designed for those over 50, has...
|
|
01.04.08
Where Is This PATH Variable Coming From?
 By
Raymond Camden
Dan Vega had an interesting issue today. He noticed that following code would work, even though he didn't create the variable:
<cfoutput>
#path#
</cfoutput>
My buddy Todd Sharp wasn't able to reproduce this yet I was. Turns out there was a simple explanation. The path value existed in the CGI scope. I was able to confirm this by just doing:
<cfoutput>
#path# versus #cgi.path#
</cfoutput>
So why couldn't Todd duplicate it? Turns out the path value was supplied by the web server as a CGI variable on the web servers Dan and I tried, but not Todd's, and since the CGI scope is one of the scopes tested when you don't fully scope a variable, the result just worked.
A few interesting things to note about the CGI scope. If you cfdump it, you won't see a PATH value. So why did it work? Since CGI variables are provided by the web server and Adobe doesn't know which CGI vars may exist, I believe that they simply used a set of common variables for the dump.
Another odd thing with the CGI scope is that you can output any variable. If you do:
#cgi.whyisraysosexy#
You will get a blank string. I believe (again, I need confirmation from Adobe on this) they did this because of the fuzzyness in what CGI variables may exist on your web server.
You could consider this an example of why you should always scope your variables, but frankly, I don't bother. I scope everything but Variables in normal CFML templates, and scope everything in CFCs. I only bother scoping Variables stuff in CFCs to help differentiate between the local (unnamed) scope and the Variables scope.
Edit: Turns out - CGI variables depend on the server and the web browser.
Second Edit - Here is quote from the CFML Reference, page 14:
By default, when you use the cfdump tag to display the CGI scope, or when you request debug output of the CGI scope, ColdFusion attempts to display a fixed list of standard CGI environment variables. Because the available variables depend on the server, browser, and the types of interactions between the two, not all variables are normally available, and are represented by empty strings in the debug output. You can request any CGI variable in your application code, including variables that are not in the list variables displayed by dump and debug output.
Comments
About the Author:
Raymond Camden, ray@camdenfamily.com
http://ray.camdenfamily.com
Raymond Camden is Vice President of Technology for roundpeg, Inc. A long
time ColdFusion user, Raymond has worked on numerous ColdFusion books
and is the creator of many of the most popular ColdFusion community web
sites. He is an Adobe Community Expert, user group manager, and the
proud father of three little bundles of joy.
|
