portal entry

Well, a first question is whether the error is coming from your browser (as a browser error) or from CF (if perhaps it's CFHTTP complaining of the problem). Can you tell? There is no CF setting I know of that would control how many redirects a cfhttp will follow (there is a setting to control whether it will follow one at all, as I will discuss in a moment). Either way, I suspect that whatever is amiss is either a coding issue (in the page being called) or a web server configuration issue (of the server being called). But here's a quick test for you, to show that cflocation works, and it will help with some following diagnostics. Create a simple test page that does nothing but the cflocation (and dumping the cfhttp scope after that). Change the URL in the cflocation to <a href="https://www.google.com" rel="nofollow">https://www.google.com</a>. Does that "work"? If so, then you know the problem is about the URL you're calling. So then the question is what makes the URL you are using have the problem. There can be many causes. Perhaps the code you call (or the application.cfm/cfc of the URL, if it's a CF page) has its own cflocation in it, thus causing the loop. Or perhaps the HTML sent back from it has its own javascript redirect. Or it could be a rewrite rule or other redirect feature configured on the web server you're calling. To help diagnose things, you could find out if the problem is happening in your browser, by using use your browser's developer tools and its network tab, to watch the files being requested from your browser. In the case of such a "redirect loop", you would want to turn on the feature on that tool's network tab to tell it to "preserve log" or its equivalent. That would prevent the list of files requests in the network tab from being wiped out as each call out sends back a new response. If you are comfortable with that, great. If not, google for using such browser dev tools (or ask here). If either it does not show repeated calls, or you don't do it, there's still another check you can make, all in CFML. In that simple test page I proposed, add a REDIRECT="false" attribute to the CFLOCATION going to your "failing" URL The dump (added in step 1) will show a filecontents variable if the URL returned some HTML or other text. But it will also show any status code returned from the URL you called. And if it's a 302, then that means that the URL you are calling is itself doing a redirect, for some reason, which would return (to your browser or to the CFHTTP) the URL *to which* the redirect would have gone.  It may be the same URL, or it may be a different one. And without that redirect="false", the underlying cfhttp process WOULD have gone to THAT URL automatically. But you could now modify your cflocation to try THAT URL. What does IT show? Again, it may be the same URL, or the first one, or it may be yet a different one. After a few such iterations, you will know why CF gave up and reported too many redirects (if indeed it was CF reporting the error). Let us know how it goes.

Comment by Charlie Arehart

I had that issue when migrating to a new version of CF and it turned out to be a session variable issue.  For example, if session.var is not defined, redirect.  Just needed to reconfigure CF session variable behavior in CF Admin to match how it was in the previous version.

Comment by Hemi345

Thank you. It seems I am also facing similar issue. Can you please advise where to configure session variable in CF Admin?

Comment by Karuna516

<p>On the “memory variables” page.</p><p>Session variables are enabled by default (in the admin), so if this is the solution I will be surprised. It would mean someone had to go to that page and disable that setting. But if it solves things, great. If not, please consider what I wrote previously.</p><p>Indeed, I would argue that even if this suggestion “works”, you should find and resolve the multiple redirects issue, which would seem related to an issue in your cf error handling.</p>

Comment by Charlie Arehart

Thanks Charlie for your detailed response. The session variable solution given by mahi not working. In first instance it seems worked. I have tried from square one.. Below are the things I did. <ol> <li>Re-installed CF 2018 developer</li> <li>Configure IIS (Windows 10) with CF 2018 using wsconfig.</li> <li>Created a simple "index.cfm" and tried to access. This page contains just cfset and cfoutput.</li> <li>got 404 error.</li> <li>updated "enable 32-bit applications" to false in IIS application pool</li> <li>404 error resolved, but getting "Too Many redirects issue"</li> <li>Upon your suggestion, enabled developer tools in IE and checked.</li> <li>getting 302 status code and it seems index.cfm is redirecting to itself.</li> </ol> Not sure what to do now? Is there anything I missed in setting up IIS with CF 2018 server?

Comment by Karuna516

Yes Charlie, As you said, this doesn't resolve my issue.

Comment by Karuna516

<blockquote> <p style="text-align: left">You need to find what's doing the redirect index.cfm. It will be one of 3 things:</p> <ul> <li>Your 404 handler in iis</li> <li>Any missing template or site wide error handler, set in the cf admin or your application.cfc/cfm</li> <li>Or other code in your index.cfm or application.cfc/cfm</li> </ul> I would isolate each of these, removing one at a time, to see which it is. This should take just a few mins on your own. Or I can help remotely, and if there's nothing else amiss it shouldn't take more than 15 mins. Let us know if you resolve it.</blockquote>

Comment by Charlie Arehart