IIS6 Bug with CFLOCATION

So, I've been trying to debug an issue with Galleon that I only saw on this server, not my local box. For some reason, whenever an IE browser posts a new message, instead of the current thread reloading, the user was pushed to the home page. (You won't see this now as I've disabled the cflocation.) I couldn't understand why, so I added some debugging.

When a new message is created, I use cflocation to reload the page so that a refresh of the browser won't repost the message. The message was being created, and the cflocation was running, but when the page reloaded, the value of the Thread ID wasn't valid anymore. Why? Because the anchor in my cflocation URL, #top, was being appended to the url value.

In other words, in Firefox, when the cflocation ran and the page loaded, url.threadid was the right string. In IE, doing the exact same operation, the value of url.threadid was theid#top.

I tried like heck to replicate this locally, but couldn't do so. Finally I created a simple test. Go to http://ray.camdenfamily.com/demos/test.cfm in Firefox and you will be pushed to test2.cfm?x=1#top. The dump you see is the URL scope. Notice that all you see is X and 1. Hit the exact same URL with IE and the value of x is not 1#top.

I did some Googling, and I did find one other user who saw the exact same thing in a .Net application under IIS6. Is anyone else seeing it?

Comments (21) Oct 8, 2005 10:06 PM Views: 4186

Comments

[Add Comment]
Not quite sure what you mean about the URL scope dump?

With that URL the value of X should be 1 and after the page has loaded the browser should try to position the page to the anchor named top.

Every browser I tried correctly shows X = 1 and tries to jump to the anchor top.
# Posted By Sean Corfield | 10/8/05 11:13 PM
Ray, I see the behavior you described (x = 1#top instead of x = 1) using IE6 on Windows XP (all the latest updates). Opera and Firefox pass the correct value and anchor. I wonder how the submission of the HTTP request differs between IE and the other browsers...
# Posted By Az | 10/9/05 12:02 AM
Ray,

I got the same results as you (using WinXP). With Firefox (v1.07) I received "x=1" and with IE6 I received "x=1#top".
# Posted By Jeff Coughlin | 10/9/05 12:09 AM
I just did a quick test on my local IIS6 test server and I get the same results using a test page similar to the one you have on your site.
# Posted By Az | 10/9/05 12:15 AM
Another quick update. This does seem to be caused by <cflocation>. If you hit the page directly with IE6 using the URL: http://ray.camdenfamily.com/demos/test2.cfm?x=1#to... then everything works as expected.
# Posted By Az | 10/9/05 12:29 AM
Hi Ray,

I would also suggest to check CF version.

Base CF 7.0 (the first version of 7) has also some problems with CFLOCATION. I had same problem on my server but after upcoming updates problem has gone.

Just an idea.
# Posted By O?uz Demirkap? | 10/9/05 4:53 AM
Sean, I just meant: cfdump var="#url#". So, odd that it didn't bug for you, and it did for everyone else.

Oguz: I'd blame CF, but the one google hit I got mentioned .Net. Anyone care to try this same experiment in .net?
# Posted By Raymond Camden | 10/9/05 6:37 AM
Also - anyone want to try this w/ PHP? My only IIS6 box is this one, so I don't want to put PHP on it just for a test.
# Posted By Raymond Camden | 10/9/05 6:56 AM
Have you tried disabling HTTP keep-alive in IIS? I experienced something somewhat similar in IIS5 a while back and that was the most effective workaround I found.
# Posted By Matt | 10/9/05 7:11 AM
This sounds alot more like a browser issue than an IIS issue. The web server should be doing the same thing regardless of browser.
# Posted By Gus | 10/9/05 8:46 AM
Ray, I meant it was unlikely to be IIS since then you'd see it with more browsers. Since you're only seeing it for Win/IE6 (and not Mac/IE), then it looks like a *browser* issue - mishandling a 302 location header - not a server error.

I notice that the actual response is: location: test2.cfm?x=1#top

You might try using a full URL (with http://ray.camdenfamily.com/demos/test2.cfm?x=1#to... instead).
# Posted By Sean Corfield | 10/9/05 4:21 PM
Sorry for misreading you. I think what I may do is a hack, simply add a dummy url var before the anchor.
# Posted By Raymond Camden | 10/9/05 7:28 PM
Did you try using the full URL instead of just the filename? I'm curious to know whether that makes a difference to IE6.
# Posted By Sean Corfield | 10/9/05 7:44 PM
As Sean says IE must be the culprit, not cflocation. We've seen the same thing with ISAPI_rewrite redirections. The simplest solution is to add an ampersand before the anchor pound sign in the url.
# Posted By Julian | 10/10/05 1:59 AM
Sean, the full URL didn't help.

Julian: I'm not so sure it is just IE as since tests locally w/ Apache don't show the same result. I'm going to try a &, and if it doesn't help, I'm going to add &dummy=1. (Not on the test, but in Galleon where I first found this bug.)
# Posted By Raymond Camden | 10/10/05 6:16 AM
Sorry Ray, I should have been more precise: it's the IIS/IE combination that seems to be at fault, rather than IIS/CFLOCATION.
# Posted By Julian | 10/10/05 6:25 AM
Just an FYI, but &#anchor seemed to work ok. I'll be releasing an updated Galleon sometime today.
# Posted By Raymond Camden | 10/10/05 7:07 AM
Ray,

I've notice this same thing happening every now and again on my dev box. It started after I installed the JRun4 Updater 6. I'm running CFMX 6.1 via JRun4 with IIS6 on Windows 2003.
# Posted By Robert Froehling | 10/10/05 8:41 AM
FYI -
<a href="http://www.macromedia.com/cfusion/knowledgebase/in...; target="_blank">http://www.macromedia.com/cfusion/knowledgebase/in...;
# Posted By Aaron West | 10/28/05 4:30 PM
I found this thread this morning. Your &#anchorName hack worked just fine. Thank you very much.
# Posted By Rob Wood | 8/10/06 5:47 PM
Thanks very much for the tip. Worked with &##anchorName
# Posted By Gordon Cantor | 2/28/08 9:19 AM
[Add Comment]