Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at cf.Objective() 2009 (Minneapolis, MN) with:

CGI.hot_n_sexy Does Not Throw A ColdFusion Error

By Ben Nadel on
Tags: ColdFusion

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:

  • <!--- 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:

  • <!--- 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:

  • <!--- 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:

  • <!--- 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.




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?

Reply to this Comment

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.

Reply to this Comment

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.

Reply to this Comment

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?

Reply to this Comment

Instead of using cgi.script_name, you can generally use getbasetemplatepath() and/or getcurrenttemplatepath(). Those are ColdFusion functions relating to .cfm file names.

Reply to this Comment

Nat,

The only issue with that is that those provide server-side paths. CGI.script_name provides a url-path.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.