CFLOCATION does not work on CF2023 Patch 7 or later

@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. 

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.

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. 

Also, what web server are you using and etc?

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.