Skip to main content
Ben Nadel at RIA Unleashed (Nov. 2009) with: Ryan Stewart and Jesse Warden
Ben Nadel at RIA Unleashed (Nov. 2009) with: Ryan Stewart Jesse Warden

Exploring Path Info And How It Interacts With ColdFusion And The Browser

By
Published in , Comments (4)

Earlier today, I blogged about using addition URL path information to solve the Save-As problem that crops up when streaming files using ColdFusion and CFContent. IIS puts this extra URL path information into the CGI variable, path_info. Before today, I had never used this, so I thought it would be good to do a little exploration to see how different aspects of ColdFusion, Javascript, and the web client itself are affected by this additional path information.

To test this, I set up a very small test page:

<html>
<head>
	<title>Path Info</title>
</head>
<body>

	<cfoutput>

		<h3>
			CGI Information
		</h3>

		<p>
			Script Name: #CGI.script_name#
		</p>

		<p>
			Path Info: #CGI.path_info#
		</p>

		<p>
			Query String: #CGI.query_string#
		</p>

		<p>
			URL Struct:

			<cfloop item="strKey" collection="#URL#">
				#strKey# : #URL[ strKey ]#
			</cfloop>
		</p>


		<h3>
			Javascript Information
		</h3>

		<script type="text/javascript">

			// Define utility method for getting the locaiton
			// values by property name.
			function Get( strProperty ){
				document.write(
					"<p>" +
					strProperty + ": " +
					window.location[ strProperty ] +
					"</p>"
					);
			}


			// Output the Javascript location properties.
			Get( "href" );
			Get( "pathname" );
			Get( "search" );
			Get( "hash" );

		</script>


		<h3>
			Web Browser
		</h3>

		<p>
			<a href="./">Same Level</a>
		</p>

		<p>
			<a href="../">Up One Level</a>
		</p>

		<p>
			<img src="./5.jpg" width="333" height="500" />
		</p>

	</cfoutput>

</body>
</html>

As you can see, this test page simply outputs the ColdFusion CGI values, the ColdFusion URL struct, the Javascript path values, and also demonstrates how the current browser will interact with the path when it comes to relative traversal and image source values.

When I run this URL:

test.cfm

... I get this output:

CGI Information

Script Name: /..../test.cfm

Path Info: /..../test.cfm

Query String:

URL Struct:

Javascript Information

href: http://..../test.cfm

pathname: /..../test.cfm

search:

hash:

The above URL has no additional path information. And, as such, it seems IIS is putting the same path into both the CGI.sciprt_name and the CGI.path_info variable. The rest of the values make sense as this is how you would normally call a web page.

Then, when I run this URL with extra path information:

test.cfm/images/sexy.jpg?download=true#content

... I get this output:

CGI Information

Script Name: /..../test.cfm

Path Info: /images/sexy.jpg

Query String: download=true

URL Struct: DOWNLOAD : true

Javascript Information

href: http://..../test.cfm/images/sexy.jpg?download=true#content

pathname: /..../test.cfm/images/sexy.jpg

search: ?download=true

hash: #content

Now that the URL has additional path information, IIS is putting a different value in the CGI.path_info value. Now, the CGI.path_info value contains the information that came after the ColdFusion template that is being executed. That is very interesting because before today, I always thought that those two values were the same. What's really cool, though, is that even though we used extra path information, the query string still came through properly; not only did CGI.query_string hold the right value, but the URL struct also had the proper name-value data pairs. Very Cool!

ColdFusion seems to play very nicely with this stuff. The real rub comes when interacting with Javascript and the web browser. As you can see, Javascript views the entire path information as the page's pathname. It does, however, properly parse out the query string, which is nice.

What you can't see in my pasted output is that the image did not load. When I right-click on the image and copy its properties, this is what I get:

http://..../test.cfm/images/5.jpg

Using the additional path information makes the browser think it is more levels deep than it really is. While ColdFusion sees us in being in the same directory as test.cfm, the browser thinks that we are in the images directory. So, while this path info stuff is very neat, it does add complexity to calculating relative web paths (assuming you use relative paths like I do).

Want to use code from this post? Check out the license.

Reader Comments

76 Comments

Yeah what happens is when using that sort of path info for SEO urls or whatever things like JS, CSS, Images etc (pretty much all hrefs/src) that are linked to will get mixed up.

In my case I was using CF to calculate the ../ required up to the app root from the current URL for each request so that I could use a relative path to the root for these sorts of things. Then I started using path info for SEO links and all failed so I found that the easiest way to fix this was to use an absolute URL to the root in all cases, then there is no issue.

15,902 Comments

@Shuns,

Yeah, I feel your pain. A lot of my site works on 404 handling. This means there is a big difference in URL between what the browser sees and what the ColdFusion server sees (CGI.script_name). It makes things a lot more interesting :) Like you were doing, I have to use CF to basically recalculate the relative web root:

../../../

At the top of the page processing. Its a pain, but once it is in place, it seems to be working fine. But I am always nervous that something is going to break :D

9 Comments

Ben,

"The above URL has no additional path information. And, as such, it seems IIS is putting the same path into both the CGI.sciprt_name and the CGI.path_info variable."

When I was creating a SES CFC to use for a project of mine, I had developed the CFC from Mike Dinowitz's SES URL UDF ... (Fusion Authority ~ Jun 04' ) ... I was thrown for quite a while trying to determine why the variable / value pairs were not showing up in the URL scope ...

It seems that IIS was converting everything to CGI.path_info ...

I ended up using a different UDF ... but, I found it strange that though the URL scope did have the variable / value's in the URL scope ... IIS did not recognize the UDF's translation as such ...

food for thought.

1 Comments

Ben,

you wrote "The above URL has no additional path information. And, as such, it seems IIS is putting the same path into both the CGI.sciprt_name and the CGI.path_info variable." That's what I experienced too.

So how do I know which URL was requested if both URLs

http://localhost/test.cfm and
http://localhost/test.cfm/test.cfm

lead to the same result

CGI.Script_Name: /test.cfm
CGI.Path_Info: /test.cfm

?

Even the result of the GetHTTPRequestData() is the same for both URLs.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel