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 CFUNITED 2010 (Landsdown, VA) with:

Strange URL Hash Problem With CFLocation In IE6

By Ben Nadel on
Tags: ColdFusion

A little while ago, it was pointed out to me that my Hayden Panettiere Free ColdFusion eCard system was not working in Internet Explorer 6. Because I am working on Windows Vista (and trying every day not to throw the computer out my window), I don't have ready access to IE6. However, since it was working in IE7 and FireFox, I have to admit, I sort of brushed this comment off and didn't pay it much head. However, I finally did get my hands a computer that had IE6 and did some testing. And, sure enough, in IE6, you couldn't get to the Preview eCard screen - it would keep kicking you out to the homepage.

After doing some quick CFDumping of the FORM and URL scopes, the problem was bewildering but obvious; CFLocation didn't seem to be handling URL hash values very well with IE6. To demonstrate what I mean, take a look at this sample code that I set up:

  • <!--- Check to see if we have the redirect command. --->
  • <cfif StructKeyExists( URL, "redirect" )>
  •  
  • <cflocation
  • url="./index.cfm?id=123##top-of-page"
  • addtoken="false"
  • />
  •  
  • </cfif>
  •  
  • <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  • <html>
  • <head>
  • <title>Untitled</title>
  • </head>
  • <body>
  •  
  • <h1>
  • Redirect Test With URL Hash
  • </h1>
  •  
  • <p>
  • <a href="./index.cfm?redirect">Redirect with hash</a>
  • </p>
  •  
  •  
  • <!--- Dump out URL scope. --->
  • <cfdump
  • var="#URL#"
  • label="URL Scope"
  • />
  •  
  • </body>
  • </html>

Here, we are providing a link that will trigger a CFLocation tag. That ColdFusion CFLocation tag has both an URL parameter (ID) and a hash value (#top-of-page). When this CFLocation is triggered in FireFox, it acts as expected and the proper ID value is moved to the URL scope:


 
 
 

 
CFLocation With URL Hash Value In FireFox  
 
 
 

However, when this page is run in IE6, we get the following output:


 
 
 

 
CFLocation With URL Hash Value In IE6  
 
 
 

Notice that the hash value (#top-of-page) is read out of the URL as part of the ID parameter. This is the strangest bug! I have no idea why this is happening and why it only happens in IE6?!? Hash values are part of the HTTP protocol, are they not? Am I just not seeing something very obvious in the code? This must be a bug in IE6... but then again, why would it have any affect on ColdFusion? These two applications are running in totally different places.

To fix this, I simply put an ampersand before the hash:

  • <cflocation
  • url="./index.cfm?id=123&##top-of-page"
  • addtoken="false"
  • />

This works fine and doesn't add any extra values to the URL scope. Strangest thing. Does anyone understand why this would be happening?



Reader Comments

@Tom,

I appreciate that. Feels like a little too much effort :)

But, really, let's not lose the point of this post. The issue is not how to test in IE6, it's that ColdFusion seems to mishandle the URL when passed from IE6. This seems extremely strange to me.

Reply to this Comment

@Ben
Could you sniff the HTTP traffic, and verify CF is sending the exact same request to both browsers when you use cflocation ?

Reply to this Comment

@Ben
Wireshark is dead easy, works on Linux and Windows. Probably Macs for all I know.
Other people swear by Charles (which hijacks the Windows proxy settings automatically) or Fiddler.

Reply to this Comment

This is very odd. I just tested on our local server and there's the same issue. Definitely an IE6 bug... which will never be fixed :/ Good thing to know there's a work around.

Oh, and it's called a Fragment Identifier, not a hash. :P Silly JavaScript with the "hash" property on the Location object confusing everyone. I guess window.location.frag would have been too violent.

http://en.wikipedia.org/wiki/Fragment_identifier

Reply to this Comment

@Elliott,

Yeah, that is totally where I was getting that terminology (from the location object) :)

Thanks for double-checking this. Good to know it's not just my machine or something. I wonder what it is about IE6 that is making the problem? Wouldn't CF know to parse the URL???

Reply to this Comment

@Ben

I don't think it's CF that's not parsing the URL, it's the web server, and I'm not really sure that's the issue either. The browser is supposed to strip the fragment identifier off the URL before it sends it to the server, and in this case it isn't, and I'm not really sure what the defined behavior is for web servers.

I have seen this used as a way to block spambots since a lot of time they send the fragment identifier to the server so you can block them that way. I guess that wouldn't work here.

Also, I don't believe that HTTP actually mentions fragment identifiers at all. It's part of the URI/URL RFC so there's some issues of what you're really supposed to do. Seems there's even some issues with how to handle redirects as a result: http://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt

Reply to this Comment

I'm guessing that this is why I long ago developed a habit of setting URL parameters that subsequently executed JS calls to do a jump after a redirect. Nice to know I don't have to do that anymore in IE 7.

What I mean is the following:

cflocation url="index.cfm?id=whatever&jump=top"

Then on the 'whatever' page, at the bottom:

<cfif structKeyExists(url, "jump)>
<script type="text/javascript">
location.hash = <cfoutput>"#url.jump#";
</script>
</cfif>

or something along those lines. Works like a champ, but it ain't clean.

P.S. Yeah, I spent several months coming within inches of blowing away my new Vista machine and re-installing XP ... only thing stopping me from doing it was uncertainty about new hardware drivers for XP.

Reply to this Comment

Yes I'm still supporting IE6 and this came in handy today ... it was starting to annoy me, but as always it's usually a simple solution! ... Thanks man! ... I know this thread is from a while back, but on a side note I use IETester to test previous version of IE just in case anyone is looking for a way to test without having to use Virtuals or older PCs.

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.