Friday, June 01, 2012

You are not going crazy CGI.PATH_INFO is empty in ColdFusion 10

Well I think the subject says it all. Today I upgraded my development and new production server to ColdFusion 10 and to my surprise a variable I was relying on to manage my routing is being passed empty on all requests. After a little googling I stumbled upon this page over at RIA Forge which stated this.

RIA Forge Page

Now I didn't just want to rely on that alone so I decided to do a test on all 3 servers I have, 8, 9 and 10 with the same page showing the same information (ColdFusion Version Number, CGI.PATH_INFO and CGI.SCRIPT_NAME)


Windows 2003, IIS 6, ColdFusion 8



Windows 2003, IIS 6, ColdFusion 9



Windows 2008 R2, IIS 7.5, ColdFusion 10



As you can see the third one does not show the cgi.path_info variable. So stop pulling your hair out and thinking it is more than just what it is. Apparently from IIS7 to Tomcat this just does not get passed. But I decided to do one more test on my Mac and it appears it is not only IIS7 but Apache is also affected and this variable is not being passed. So if you really need this and you are going to 10 lets hope the Tomcat team does something to remedy soon or come up with a different solution. Remember there is always more than 1 way to skin a cat.

Mac, Apache, ColdFusion 10



Code Example

Below is what I did to work with this issue in a current project. Since several developers using different platforms are on this single project I wrote it with that in mind. Basically save the final variable output into the request scope in case I need it anywhere else thru the request. This is set on the onRequestStart function of my APplication.cfc



Update

This is an output of what I use to get from CF9 using cgi.path_info, check out the URL and the output.



BTW * the domain used is not a real one, this is a local url I defined in my host file, in case anyone tries to go to it :). giancarlo.com actually belongs to someone else.



23 comments:

Ryan said...

I just ran into this today. I wasn't sure it was a CF10 issue but I had my suspicions. Thanks for tracking this down writing this up.

I'm going to do some googling, but I think I'm about 20 minutes away from uninstalling CF10 and going back to CF9.

Ryan said...

Now I've found that the PATH_INFO value only becomes empty when I have my URL Rewrite rule enabled on the server. If I take that out, I do get a value for PATH_INFO. Of course, my site won't work without this rewrite rule! I haven't found a work around yet.

Giancarlo Gomez said...

Hello Ryan,

Depending on what server you are working on there are some options. Below is a snippet that should work on IIS6 if using Ionics Isapi Rewrite Filter, IIS 7 if using URL Rewrite or Apache when using mod_rewrite.

if (structKeyExists(cgi,"http_x_rewrite_url") && len(cgi.http_x_rewrite_url)) // iis6 1/ IIRF (Ionics Isapi Rewrite Filter)
request.path_info = listFirst(cgi.http_x_rewrite_url,'?');
else if (structKeyExists(cgi,"http_x_original_url") && len(cgi.http_x_original_url)) // iis7 rewrite default
request.path_info = listFirst(cgi.http_x_original_url,"?");
else if (structKeyExists(cgi,"request_uri") && len(cgi.request_uri)) // apache default
request.path_info = listFirst(cgi.request_uri,'?');
else if (structKeyExists(cgi,"redirect_url") && len(cgi.redirect_url)) // apache fallback
request.path_info = listFirst(cgi.redirect_url,'?');
else // fallback to cgi.path_info
request.path_info = cgi.path_info;

// finally lets remove the index.cfm because some of the custom cgi variables don't bring it back
// like this it means at the root we are working with / instead of /index.cfm
request.path_info = replace(request.path_info,'index.cfm','');

Charlie Arehart said...

Giancarlo and others, I'm curious: while you await the possibility that Adobe may identify this as unintentional, why not just change your code to use script_name when you want the "script path/file", and only use path_info when you really want "extra path info" (such as the 123 in index.cfm/123), which in most other servers is the real intended distinction?

Giancarlo Gomez said...

Hello Charlie, the problem for me is that I was using it for the "extra_path" info so I can do my internal routing and path_info would give me this. Regardless, there are workarounds with the variables I mentioned above that are set by the URL rewriters.

I also updated the post to show what it would show me in 9.

This required me to reinstall cf9 on my mac and now I have both 9 and 10 working. A little note, the new 9.0.2 installer is missing the osx64 bit apache connector, after installing CF you have to go get the wsconfig.jar from hot fix CVE-2009-1876 in order to get the required connector. A little frustrating you can say.

It can be found at http://www.adobe.com/support/security/bulletins/apsb09-12.html

Charlie Arehart said...

Thanks for the updated info. Hope it may help other readers resolve issues. Cheers.

Jim Stout said...
This comment has been removed by the author.
Tim B said...

Wow, they marked this as "NotABug" in the adobe bug base. How is this not a bug? We need someone to get their attention on this so it can get fixed.

https://bugbase.adobe.com/index.cfm?event=bug&id=3209090

Chuck Dorey said...

Migrating from Coldfusion 7 to Coldfusion 10 and came across this issue. Based on how we were using CGI.PATH_INFO I found that GetPageContext().getRequest().getRequestURI() gave us the equivalent result. A pain to do a global find and replace but I also don't need anything installed like URL Rewrite to have a workaround.

EdwardBeckettX said...

try REQUEST_URI ... :-)

Ryan said...

This has been fixed in the 10.0.1 update released this weekend!

http://blogs.coldfusion.com/post.cfm/coldfusion-10-update-1-10-0-1-released

Anonymous said...

Ryan,

Adobe says that it has been fixed, and perhaps it is when URL rewriting is utilized, but I've upgraded four different CF10 servers to the Update 1 (10.0.1) release at work today and none of them are showing any information in the CGI.PATH_INFO field. The variable still remains blank, post-update.

All systems are running Microsoft Windows Server 2008 R2 (64-bit) that are new builds and basically stock. HTTP Redirection is not installed. For kicks, I even updated the Java VM to 1.70_07 to see if that would affect anything (it didn't).

I've gone back to using either CGI.SCRIPT_NAME or the Java servlet alternative to CGI.PATH_INFO, GetPageContext().getRequest().getRequestURI(). There is an extensive use of PATH_INFO in our code, particularly with our custom CMS and its libraries, and this kind of move really puts our future dependency of ColdFusion into question.

Giancarlo Gomez said...

Edward that didn't work wither before the update. Ryan, thanks but I had already blogged about it on the day of the release (http://www.giancarlogomez.com/2012/08/coldfusion-10-update-1.html). Willfull go thru my blog entry and it may be that you didn't reconfigure the sites again with the web connector (required only in windows as per my tests).

Anonymous said...

Giancarlo,

Thank you for pointing out the step of running the web connector after the update. Once I did that, and ran my test again, I can now see that PATH_INFO is being populated by the server. Feel bad for missing out on an instruction, but thankful for your reminder.

Back to work!

Alfonso Huerta said...

Giancarlo,

What if after following all this steps, even removing and adding back the sites on the Web Server Configuration Tool and still cant see the cgi.path_info var. Im working on CF10 x64. Any suggestions?

Giancarlo Gomez said...

Alfonso make sure you run all the updates after installing CF, this issue has been fixed already.

Alfonso Huerta said...

The Thing is that I already did, but still not working properly. I guess I'll have to reinstall and try again

akash bavlecha-html programming said...

Hi Giancarlo,

Similar issue we are facing even after multiple installs and re-installs of CF10. I also tried re configuring the IIS connector and also installed separate hotfixes. We tried with only update 1 and with all updates together however in all the cases CGI is giving cgi.path_info as blank. I also found that request_url also doesn't exist. I also tried different approaches mentioned in the same blog but not really helpful.

We have an application which uses CGI.path-info in many pages and could not encounter the exact cause of this till now.

Below is the detail of configuration i run for cf10.
---------------------------------------------------------------------------

java.version == 1.6.0_29 (Java 1)
java.vm.name == Java HotSpot(TM) 64-Bit Server VM
java.vm.vendor == Sun Microsystems Inc.
java.vm.version == 20.4-b02
java.vm.specification.name == Java Virtual Machine Specification
java.vm.specification.vendor == Sun Microsystems Inc.
java.vm.specification.version == 1.0
java.specification.name == Java Platform API Specification
java.specification.vendor == Sun Microsystems Inc.
java.specification.version == 1.6
java.vendor == Sun Microsystems Inc.
java.vendor.url == http://java.sun.com/
java.class.version == 50.0
java.compiler == null
java.home == C:\ColdFusion10\jre
java.io.tmpdir == C:\Windows\TEMP\
os.name == Windows 7
os.arch == amd64
os.version == 6.1
path.separator == ;
file.separator == \
file.encoding == Cp1252
user.name == AKASHBA-WIN7$
user.home == C:\
user.dir == C:\ColdFusion10\cfusion\bin
user.language == en
user.region == null

----------------------------------------------------------------------

I would highly appreciate any help on resolving issue soon.

admin said...

Even after updating to ColdFusion 10 Update 5, we still do not see any information in CGI.PATH_INFO. Any ideas on what to do now?

Jose Galdamez said...

Many thanks for this post. I'm working on a CF8 to CF10 upgrade and this app uses CGI.PATH_INFO to reference the current template's path from the Web root. Fortunately, all I had to do was a global find/replace to CGI.SCRIPT_NAME and that fixed it.

Ryan said...

"Even after updating to ColdFusion 10 Update 5, we still do not see any information in CGI.PATH_INFO. Any ideas on what to do now?"

Did you uninstall and reinstall the connector? This is necessary for resolving the issue.

DistributorCentral said...

Yes, more than once.

Doug Odegaard said...

Thank you so much for posting this. I indeed did think I was crazy. I did think it was CF 10 issue since I upgraded from 8 to 10 and this began happening. Appreciate the blog post.