ColdFusion CFLocation Only Passes Referrer Of The Referring URL
Posted May 16, 2007 at 3:36 PM by Ben Nadel
That sounds really confusing, but it was causing me some headache on a production site today. I was redirecting a user to a given page and then trying to check which page they came from. The CGI.http_referer value kept coming up empty. But how is that possible? Clearly the user was coming from another page!
After a little bit of testing, it seems that CFLocation passes along the CGI.http_referer value of the referring page, NOT the URL of the page with the CFLocation tag on it. Take a look at this test page that I set up (cflocation_referrer.cfm). It is designed to refresh in one of two ways: an actual link or a ColdFusion CFLocation call:
- <!--- Kill extra output. --->
- <cfsilent>
-
- <!--- Param URL variables. --->
- <cfparam
- name="URL.cflocation"
- type="string"
- default="No"
- />
-
- <cfparam
- name="URL.relocate"
- type="boolean"
- default="false"
- />
-
-
- <!---
- Check to see if a CFLocaiton call has been requested.
- If so, we are just going to CFLocate back to self.
- This will allow us to see what the referrer is seen
- as by the target page.
- --->
- <cfif URL.relocate>
-
- <cflocation
- url="#CGI.script_name#?cflocation=Yes"
- addtoken="false"
- />
-
- </cfif>
-
- </cfsilent>
-
- <cfoutput>
-
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <html>
- <head>
- <title>ColdFusion CFLocation And HTTP Referer</title>
- </head>
- <body>
-
- <p>
- CFLocation: #URL.cflocation#<br />
- Referrer: #ListFirst(
- ListLast( CGI.http_referer, "\/" ),
- "?"
- )#
- </p>
-
- <p>
- <a
- href="#CGI.script_name#"
- >Refresh</a>
-
- |
-
- <a
- href="#CGI.script_name#?relocate=true"
- >Refresh With CFLocation</a>
- </p>
-
- </body>
- </html>
-
- </cfoutput>
Notice that if you click on the first link, the page just links right back to itself. When you do that, the rendered page gives us this output:
CFLocation: No
Referrer: cflocation_referrer.cfm
The other link links back to itself but flags that a CFLocation should be called to forward the user to the next page (which for testing is also the same page). The rendered page gives us this output:
CFLocation: Yes
Referrer: cflocation_referrer.cfm
Notice that CFLocation was used (YES) and a CGI.http_referer value was available. When I saw this, I was like WTF mate? So then I thought maybe the difference was that this was a development server and the other was a production server. I uploaded this file to the production server (Shhhhhh!) and ran it there. Same exact result!
I started to think I was going crazy. What was going wrong in my other code such that the referring URL was being lost. What was different? Then it occurred to me! On the production server, the page that launched the ColdFusion CFLocation tag was being accessed directly by the user. Meaning, they were manually entering the URL that then cause the CFLocation to take them to the next page:
User enters pageA.cfm in browser location
pageA.cfm performs CFLocation to pageB.cfm
pageB.cfm had no CGI.http_referer value
That was a difference I could test by calling my test page manually. If you look at the code above, when I click on the link, the page refreshes and sees that is should perform a CFLocation. The page then refreshes again to take the user to the CFLocation target page. This is two refreshes. To mimic the production server scenario, all I have to do is manually enter the relocate URL. This will only cause one refresh.
So, when I enter:
./cflocation_referrer.cfm?relocate=true
... directly into the URL (thereby circumventing the first refresh), the rendered page gives us this output:
CFLocation: Yes
Referrer:
As you can see, we are sill using the CFLocation (YES), but this time we have NO referring URL value.
So what does this mean? It means that if PageA CFLocates to PageB, PageB can only see PageA's CGI.http_referer value, NOT its own CGI.http_referer value (which should be PageA). This is very strange to me. The way CFLocation works (as far as I know) is that it actually sends a header value back to the client/browser which then launches a new HTTP request to the target URL. In that case, when the browser gets the CFLocation request, it is sending the control from PageA to PageB. Wouldn't this make PageA the referrer of PageB?
Reader Comments
@Ben
Might be worth looking at a javascript solution instead (something along the lines of an onload script that performs a document.url = pageB). I believe that then you would have the expected referrer value (pageB actually came from pageA, even though the user was automatically forced there).
(forgot to add this in my above response)
CFLocation does not send a full page to the browser, it only sends the header with the new location. What this means is that technically, the client might have asked for page A, but in reality they only got a header response pointing them to page B. The actual loading of Page A and then Page B only occurred on the web server. By doing the javascript method that I suggested, the client machine actually loads page A, then gets pushed to go load page B.
@Ben,
Keep in mind that referrer info is controlled by the browser. Hence, it can be switched off or even even intentionally spoofed by the user. Different browsers may also behave differently.
Perhaps the reason for the behavior you are experiencing lies in how browsers interpret HTTP redirect codes (I'm not sure which one cflocation uses). E.g., code 301 ("Moved Permanently") would indicate to me that the behavior you described would actually be wanted by the server (i.e., the page moved, so you don't want the referrer to simply be the old URL).
Hence, the title of this post is erroneous (ColdFusion never passes referrers). ;-)
@Rich,
Yeah, a Javascript page would probably handle it fine, just perhaps a slightly longer drag between pages A and B. I understand that at that point (CFLocation) only headers get sent back, but in terms of client-server contact cycle, it feels like a new cycle.
@Steve,
This is a very good point. In fact, I was working with a client the other day who's firewall was stripping out all referrer in formation for each outgoing request. Basically, I agree that CGI information in general cannot be "depended" on (but I still use script_name).
Plus, I see what you are saying about the redirect and "what" the server wants you to see.
All to say, it was just something I never thought of before and I only came across it when I was trying to implement a quick fix... just goes to show you - quick fixes don't pay!
... actually I think this is the second title this week that was dead wrong in it meaning :) The first being that XML nodes are passed by value.
Ben,
have you tried using the redirect method in Java? I don't remember the exact syntax but something like getPageContext().forward("url"). Just curious if that might keep the referrer.
@Boyan,
I don't know if it will track that way. I will have to give it a shot.
So then, since Google appends its search info within the URL (i.e. /search?hl=en&q=coldfusion+cgi+variables). Are we able to grab this search info and place it into a session when someone gets to a site? This would be very important in tracking a user for online marketing purposes. Doing so would allow us to track whether a users completes a desired call to action on website.
This article looks pretty old, but thanks Ben for posting. You saved me hours from trying to solve the same problem. I am trying to control how my pages get shared so I setup certain pages to look at the http_refer to ensure it was coming from designated pages on my site. Some of those designated pages literally were just redirects using CFLOCATION so my code would fail because the final landing page would still think someone was coming from a 3rd party site and not the page (with the CFLOCATION tag) within my own site.
