CFLOCATION does not work on CF2023 Patch 7 or later

[bartlebyBC]

Hello, everyone. After installing Patch 7 of ColdFusion 2023 on an existing application, the CFLOCATION tags stopped redirecting. It was redirecting properly until Patch 6. The page indicates a status code 302 in the 'network' tab of Google Chrome and shows that the next page loaded, but visually, it seems as if it didn’t load. Has anyone experienced this and knows how to solve it? Thank you all for your help.

[BKBK]

That sounds serious. Could you please share some code with which we can test?

In any case, why didn't you just install the latest update, namely, Update 13? That is the usual thing to do.

[bartlebyBC]

Hello! Thank you for the response. I noticed that this started from Patch 7... I updated to later versions hoping the redirection would start working again, but it is still having issues. Currently, I am testing on version Patch 13.

[bartlebyBC]

This is the screen of the form where the redirection will be performed. I also included the result of the 'Network' tab to show what was loaded

On next page where the redirect will be performed, I only left a CFLOCATION to a local HTML page.
<cflocation addtoken="no" url="manutencao.htm">

When running the page, note that the redirection is performed (Status 302), but the page is not loaded. When I was using up to patch 6, it would display the page set in the redirection.

Answering another participant's question, this is a Microsoft Windows 11 environment, with IIS as the WebServer.

[MIK?L]

Ah, Win 11. I don't have a box to test it on. 

At home I'm Win 10 with IIS at work I'm server 2019 with IIS. 

[MIK?L]

Also, what web server are you using and etc?

[bartlebyBC]

I am testing in a Microsoft Windows environment (IIS Web Server Structure). (On my development machine with Windows 11 and on a production server with Windows Server 2018. Both exhibit the same behavior.)

[MarkTakata]

OK, so putting on my debugging hat.
If network tab says a 302 occurred AND shows the next page loaded, CF has done its job (at least so far as cflocation is concerned).  The issue is almost certainly not with cflocation (it, after all, delivered the page to the browser) but with something else interacting with patch 7.
As BKBK says, my gut would be to push out to the latest patch and see if that fixes the issue. But if you cannot (or if you do and the issue continues) I would do the following:

1) Make a really basic cflocation page. pagea.cfm that just does:

<cfscript>location("pageb.cfm");</cfscript>
Then have pageb.cfm render out the timestamp (so you know cf is involved in the rendering of the second page). If THAT works then:

2) Check the logs in cfadmin. Sometimes the errors don't quite make it up and out to the browser's network stack trace. See if there's something horrible occurring deeper in. If that's all clean then...

3) I would check that the page you're trying to render (i.e. the one being redirected TO) renders. You may have to mock data to do this. If that works...
4) Then I would debug and trace the variables being passed to that page from the initial cflocation page. Are they what you're expecting?

Basically if what you're saying is true, step 1 will fail. I think the issue lays somewhere deeper and further along in the code though. A TON of people use cflocation and that's a very old patch. We probably would have heard about it over a year's time. 

[BKBK]

An idea: if the cflocation line makes use of a dynamic variable, then use a fully-scoped name. For example, in place of

<cflocation url="#dirName#/#somePage#" >

use the appropriate scoped names:

<cflocation url="#url.dirName#/#variables.somePage#" >

or

<cflocation url="#form.dirName#/#form.somePage#" >

etc.

[bartlebyBC]

Good suggestion, but even when performing redirections with static pages and addresses, the problem persists.

[Dave Watts]

I find it really difficult to believe that this behavior is caused by a CF patch, since you're still getting the appropriate response from the server. Try a different browser and see what happens.

[BKBK · Accepted solution]

@bartlebyBC , your example suggests that there are 2 serial redirects, proceeding as follows:

formPage.cfm -> validacao.cfm -> manutencao.htm

<!--- formPage.cfm --->
<cflocation url="validacao.cfm" > 

<!--- validacao.cfm --->
<cflocation url="manutencao.htm" > 

If that is so, then validacao.cfm will not be displayed. Furthermore, the page will have status code 302.

Note: the above idea includes the case where the redirect is done by Javascript. So check the Javascript in each file on the request path.

[Charlie Arehart · Accepted solution]

@bartlebyBC, I have some different diagnostics for you to attempt, and a different suggestion of what may be amiss. Both are slight variations of what's been offered so far. A couple are quite simple. 

1) First, please try redirecting to some page NOT in your app, like https://google.com. Does that work? If so, that proves cflocation is not broken. And as Mark said, and your 302 shows, it doesn't seem that was really not your problem.

But please prove it for yourself.

And yes, I realize your second test was redirecting to an html page. Let's take both cf AND your web server out of the picture for this test.

Please let us know that result. 

2) Assuming it does, then we need to understand what's really NOT working. And for that I have other suggestions. 

2a) Since it "didn't work" for an html page (you say it showed blank), please click on that resulting htm file in that network tab. That opens details on that one returned page. Open the "response" tab that shows what exactly was returned. Do you see the html you expect? If not, again that's then not about cf, since it's an html page. 

2b) And just to to be clear, are you 100% sure nothing else changed, including in your web server? 

2c) Further to that last point, you've not said that if you go BACK to update 6, the problem goes away. If it did NOT, then that would PROVE it was not about the cf updates. (BTW, that's what cf calls them, not patches. It may seem a pedantic point, but you'll help yourself in doing research since most discussions and blog posts follow that nomenclature.) 

But I appreciate that going back to update 6 may not be desirable or possible for you.

3) Finally, rather than await your reply on the above (and even before you may do that test of rolling back the update), I'll make one last proposal, and it's an easy one to try. 

First, considering that you find that the failure is after update 7, have you yet read the update tech note about that specific update?It was indeed a very important one. The most significant thing was a change regarding how cf processes variables without a scope prefix.

It's NOT that "you MUST now  prefix all vars" (as some read it), but instead it's that if you don't--and if cf can't resolve the variable from scopes available within the request--it no longer (by default) looks to resolve them via scopes populated from OUTSIDE the request (like url, form, cgi, cookie, etc.) Again this is detailed in the technote or my and their blog posts from that time of March 2024. Both also discuss alternatives to "having to find and change a thousand variable references". But hold that thought. 

3b) So as a final suggestion, and if the simple tests above DO work, then going back to your original code (which was really trying to do a cflocation to that next cf page in that form processing), let's put some simple text and a cfabort at the top of that cf page you're redirecting to. Do you see THAT? 

3c) Better still (or if you don't), we should next suspect it's possibly about an impact of the update on whatever application.cfm or application.cfc you have. We can diagnose that, with the same sort of "show some simple text and cfabort", but it's perhaps a challenge in this case. 

Do I read you right that you're using one page for the form, another for its action, and another you redirect to? If so, we can't do the abort with that code, because the submit of the form to the action page would prevent the cflocation. 

You could hold off saving the change until the for is onscreen and then put the cf location above the cfabort: that would let the form show, and while we'd not see the text from the action page, the cf location now above the abort WOULD run and you SHOULD see the simple text on the 3rd page in the process. Do you? 

Sorry for so many words. As often is the case (especially for seemingly knotty problems), there can be many things to consider. And if it was easy to solve, you'd have perhaps already solved it.

Let us know what you find, or let us know as well if you'll not do any or all of the tests here for some reason. 

[bartlebyBC · Accepted solution]

Good morning, everyone.

Sorry for the delay in responding, but I'm returning from a holiday and had been running some tests earlier.

Thank you for all the suggestions. I managed to do the redirection, and the issue really wasn’t with CFLOCATION.

It was in a script that was executed beforehand to validate the form, and this validation was done using an "IsDefined" function.

Even though I added the parameter "--Dcoldfusion.searchimplicitscopes=true" in the JVM settings, I had to set the variable scope to "form." After including it, the execution was completed, allowing the process to reach CFLOCATION, thus finally performing the redirection.

[Charlie Arehart]

Thanks for the update. But the reason your jvm arg didn't work is you mistakenly put 2 dashes in front of it. It should be only one.

If you found that form offered somewhere online and you can't point out their mistake or get it corrected, let us know where it is and maybe we can press the point.

Finally, it could help future readers to mark my reply (and its point 3 suggesting the scope matter as the possible explanation and solution) as an "answer".

Bottom line: glad things are resolved for you. 

[BKBK]

I think the 2 dashes in

--Dcoldfusion.searchimplicitscopes=true

are just a typing error. I say this because I believe that, with those two dashes instead of one, the Java Virtual Machine would not have allowed ColdFusion to start.

[Charlie Arehart]

So @bartlebyBC , which is it? 🙂 I got notification about 90 mins ago that you had marked both replies above (and others) as "answers"...but they conflict with each other. You're the ultimate judge: what was the result? That will be as valuable as the marknig of "answers", which of course is appreciated.