We had another of those time-sucking mysteries yesterday, when we had a problem with a page that was supposed to redirect to another page using a ColdFusion cflocation
tag– but didn’t.
The page is a form page that submits to itself, does some processing, including talking to a third party gateway, and then redirects to a “you’re done” page. It was undergoing heavy re-development, so we had lots of cfdumps
going on, so we could see the data structures being generated, and a cfabort
to stop the processing– in this case, the redirect– so we could see how the processing was happening.
Came the point when it looked like the processing was working, and were getting the results we were expecting, that we took the cfabort
tag off, expecting the page to relocate to the “you’re done” page. It didn’t; it just sat there; the cflocation
tag wasn’t working.
I may have said a few bad words.
How cflocation
works
What the cflocation
tag does is tell the web server to send the browser a special invisible HTTP header (technically, by default, a 302 – Moved Temporarily header) that tells the browser to go to a different location. The browser then requests the destination page, rather than receiving the contents of the original page.
When the redirection failed, the first thing I did was use a Firefox extension the makes the invisible HTTP headers visible. The redirect headers were indeed not being sent.
The next thing that occurred to us was that possibly we were flushing the contents of the page somewhere along the line using the cfflush
tag, which flushes the ColdFusion buffers out to the browser before ColdFusion finishes generating the page. With a large page with a lot of generated content, the cfflush
command can make the page feel more responsive, since content starts appearing in the browser before the page is completed, but it can also interfere with headers being sent to the browser, so we searched all the pieces of the page to see if there were any cfflush
tags we hadn’t noticed. There weren’t.
We tried outputting some content before and after the tag; the content before appeared, but the content after didn’t.
Another theory we checked out was that there was some sort of error happening around the tag that was being caught somehow. So we put a try/catch block directly around the cflocation
, with an error dump inside the catch, to see if it was failing silently. It wasn’t.
It was time for some brute force debugging. I put a cflocation
tag higher in the page. It worked. I put it a little lower. It worked again. I moved it lower still, and it stopped working. Aha. Now I knew approximately where the issue lay. I kept moving the tag until I knew exactly what the culprit was.
cfdump
blocks cflocation
A cfdump
tag, which is a ColdFusion development tool to “dump out” a complex data structure was the culprit. As I’d mentioned, the page was under development, and we had lots of dumps of lots of structures coming back from our underlying objects. Generally, removing those dumps are part of the process of “putting the covers back on” a page, so we hadn’t removed them yet, but they were preventing the browser from relocating to the final page. We cleaned the page up, and it worked like a champ.
My theory is that cfdump
is doing a cfflush
internally, to make sure the HTML comprising the dump display gets sent to the browser. If this is true, it would also prevent ColdFusion from setting cookies on the page.