No hurry on this one. It’s more curiosity than emergency.
No error templates are defined.
intepub/wwwroot/index.cfm consists of 16 characters: you must be lost
browse to machine’s ip from anywhere, “you must be lost” comes up.
browse to localhost from local machine … same result.
browse to 127.0.0.1 from local machine…
it forwards to this address:
And shows what I think is a Chrome error page:
“127.0.0.1 redirected you too many times.
Try clearing your cookies.
This is not a showstopper, but why would 127.0.0.1 produce a different result than localhost?
Don’t forget to tell us about your stack!
OS: Win Server 2019 Datacenter (10.0) on AWS Java Version: 11.0.6 Tomcat Version: 9.0.34 Lucee Version: 188.8.131.52
I’m seeing this for the first time. Tested it with the same results, but may be I’ve never seen this before, because I never access 127.0.0.1 through IIS port 80, but directly through 127.0.0.1:8888 for administrational tasks only.
I think this issue is mod_cfml related, it is causing indefinate 307 Redirects. Here is a snippet of the access log:
Not really sure why, may be @Jordan_Michaels can take a look. But for now as a workaround, you could deactivate mod_cfml by editing server.xml like so:
Edit server.xml at pathToYourLuceeInstallation\tomcat\conf\server.xml, find the section of the valve mod_cfml, <Valve className="mod_cfml.core"... /> and set as a comment to <!-- Valve className="mod_cfml.core"... / --> and restart the tomcat service.
By deactivating mod_cfml, the host entries will not be created by mod_cfm anymore, and you’ll have to add them manually to your server.xml files.
Also important to know is that tomcats default 127.0.0.1 address points to its default webroot at C:\lucee\tomcat\webapps\ROOT. If you have set localhost to serve the content of C:\inetpup\wwwroot (added by cfml_mod through IIS/boncode), they won’t serve the same content. If you want both addresses to serve the same content, you’ll need to add a ROOT.xml file at C:\lucee\tomcat\conf\Catalina\127.0.0.1\ROOT.xml with the following content:
This issue occurs NOT because of a problem with mod_cfml, but because of a problem with the underlying stack. Specifically if there is an issue with Tomcat that affects mod_cfml’s ability to create a new context. Because of the underlying issue, mod_cfml gets stuck in a loop: mod_cfml sees new context, issues command to create new context then redirects, new context doesn’t get created due to underlying issue, and the process repeats.
One proposed solution is to create a “break” that would simply pass the default context if a URL variable was detected (like the &__ string), but that is not a fix for the underlying problem. If we leave mod_cfml without a break, a user can identify that there is an underlying issue and take steps to correct it.
If you get this, simply try restarting Tomcat. If that doesn’t work, try creating the context manually and see what error you get - as that will point you to the underlying issue.
Yes, I’m completely confused, but that’s not a high bar.
Interesting discussion, anyway.
I’ll not be pursuing this further. It’s not an issue for me.
Smarter people will likely fix it in a future release.
Besides, I found a scarier one, which I’ll post in a bit.
Sorry to dredge up an old post like this, but I was wondering if anyone has solved this issue?
I’m trying to setup a default site in Ubuntu on AWS. I’m running Lucee behind Nginx. Previously all my sites were configured in server.xml, but I need mod_cfml to setup the default site for the load balancer health check, as the host will be the server’s IP address and this won’t be known when I’m creating the configs.
If I setup mod_cfml, the context is created correctly, but doing a curl reveals an endless loop of 307 redirects, adding an additional &_ each time.