CGI.hot_n_sexy Does Not Throw A ColdFusion Error
Posted October 24, 2006 at 10:40 AM
My co-worker was going through some of my code and spotted an error that I had made when using a CGI variable. I had misspelled the key "script_name". The reason that I had not caught it was because ColdFusion did not throw any error. Strange. When I did some more testing on this, it seems that you can basically access any key in CGI and will not throw an error:
Launch code in new window » Download code as text file »
- <!--- Access invalid key. --->
- <cfdump var="#CGI.hot_n_sexy#" />
Works totally fine. Returns an empty string (probably because Java is returning a NULL value).
I know this sort of thing usually doesn't work, but I tested it in another scope:
Launch code in new window » Download code as text file »
- <!--- Access invalid key. --->
- <cfdump var="#URL.hot_n_sexy#" />
Ok, this throws the error:
Element HOT_N_SEXY is undefined in URL.
Now, both of these are ColdFusion scopes, so I am curious as to why one throws an error and one does not. To investigate, I dumped out the class chain that makes up the CGI and the URL scopes:
Launch code in new window » Download code as text file »
- <!--- Output CGI class chain. --->
- CGI:
- #CGI.GetClass().GetName()#
- #CGI.GetClass().GetSuperClass().GetName()#
- #CGI.GetClass().GetSuperClass().GetSuperClass().GetName()#
-
- <!--- Output the URL class chain. --->
- URL:
- #URL.GetClass().GetName()#
- #URL.GetClass().GetSuperClass().GetName()#
- #URL.GetClass().GetSuperClass().GetSuperClass().GetName()#
- #URL.GetClass().GetSuperClass().GetSuperClass().GetSuperClass().GetName()#
This gives us the output:
CGI:
coldfusion.runtime.CgiScope
coldfusion.runtime.Scope
java.util.AbstractMap
URL:
coldfusion.filter.UrlScope
coldfusion.runtime.LocalScope
coldfusion.runtime.Scope
java.util.AbstractMap
As you can see, both ColdFusion scope ultimately extend the AbstractMap class. If you look at the Get() method of the java.util.AbstractMap, you will see that it can either return a null value or thrown an error depending on wether the Map allows null values. The ColdFusion wrappers (that extends the AbstractMap) must determine wether null values are allowed.
And just to make sure I am not going crazy, I ran the ContainsKey() method on both the URL and the CGI scopes to see if the invalid key shows up as existing:
Launch code in new window » Download code as text file »
- <!--- Check CGI key. --->
- #CGI.ContainsKey( JavaCast( "string", "hot_n_sexy" ) )#
-
- <!--- Check URL key. --->
- #URL.ContainsKey( JavaCast( "string", "hot_n_sexy" ) )#
This gives us:
NO
NO
So, it seems that neither scopes have the key (which we pretty much knew already), but apparently, the coldfusion.runtime.CgiScope class allows NULL entries while coldfusion.filter.UrlScope does not.
Download Code Snippet ZIP File
Post Comment | Ask Ben | Other Searches | Print Page
Newer Post
ColdFusion Query of Queries Creates BIGINT Values When Hard Coding Integers
Older Post
Skin Spider : Moving Application.cfm To ColdFusion MX 7 Application.cfc
Reader Comments
I asked someone about this a few years ago at one of the CF Dev Cons. IIRC, it's because they found out that a lot of people were relying on CGI variables that might or might not exist. Back in the olden days of the intarweb, not all browsers sent things like User-Agent headers and Host headers and the like. And yet, a ton of code proliferated that relied on CGI.HTTPUSERAGENT and CGI.HTTP_HOST. The Dev told me that it was deemed better that the scripts found empty values than blew up altogether.
A contradictory story that I heard, one which I am more likely to believe, was that older versions of some web server APIs (I think maybe NSAPI? or Apache?) didn't allow you to definitively test for whether or not a CGI variable (thus, really, an environment variable) actually existed -- it always returned an empty string if it didn't exist. Thus, for compatability, all implementations needed to emulate that behavior.
I also hazily remember something back from the 3.x or 4.x days about it being "too expensive per request" to populate the CGI variables, and thus they weren't populated until you first tried to access them. Maybe this has something to do with it?
Rick,
Thanks for the input. I wonder if there is a way to set a flag that will force it to throw errors. Seems like a strange thing to allow happen these days.
It's still relevant these days, sadly, due to differences between web servers in what variables they provide - but I totally agree, CF could handle this better in the borderline cases. I had a run-in with this last year, relating to the different ways webserver handle redirects:
http://instantbadger.blogspot.com/2005/05/apache-404-cgi-weirdness.html
Also, custom header information can be applied by custom filters run within the web server--which is why the CGI scope was designed to return an empty string if the key isn't explicitly defined.
One reason I don't rely on the cgi.script_name is that not all web servers return it. I really try to avoid using the CGI scope when at all possible.
Dan,
I happen to love the CGI.script_name varible. How do you code without it? Is there something that you use inplace of it?
Instead of using cgi.script_name, you can generally use getbasetemplatepath() and/or getcurrenttemplatepath(). Those are ColdFusion functions relating to .cfm file names.
Nat,
The only issue with that is that those provide server-side paths. CGI.script_name provides a url-path.
I Just Bookmarked Your Site,
