Exploring Path Info And How It Interacts With ColdFusion And The Browser
Posted July 18, 2007 at 4:11 PM by Ben Nadel
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).
Reader 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.
@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
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.
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.
