Hi Support,
The following spec is my current stack.
OS: Ubuntu 20.04.2 LTS
Java Version: openjdk 11.0.11 2021-04-20
Tomcat Version: Tomcat 9
Lucee Version: 5.3.7.48
I setup the latest Lucee with the reference of Pete Freitag (foundeo) docs “GitHub - foundeo/ubuntu-nginx-lucee: Script for standing up a Lucee server using nginx and Tomcat on Ubuntu” That repo is awesome. Deployment went smooth though.
Currently I am facing an issue with a site which is throwing an error “307 Internal Redirect”
I have setup two website which one is working fine and another one has a problem of internal redirect.
This is the virtual host details of problematic one:
root@ft.com:/etc/nginx/sites-available# cat ft.conf
server {
listen 80;
server_name ft.com;
root /web/lucee.ft.com/wwwroot/ft/www/htdocs;
Mod_cfml (Lucee) specific: add a unique ID for this server block.
set $lucee_context “ft.com”;
include lucee.conf;
}
When I am trying to access this site by “http://ft.com/test.html” “HTTP” that is redirecting to “HTTPS” which is giving 307 Internal redirect issue. test.html is a simple file, please see the content of the file and error screenshot
cat test.html
Hello!
I mentioned one site is working without this error so please see the virtual host information for that:
cat lucee.ftadm.com.conf
server {
listen 80;
server_name lucee.ftadm.com;
Mod_cfml (Lucee) specific: add a unique ID for this server block.
set $lucee_context “lucee.ftadm.com”;
include lucee.conf;
}
The difference is working one root directory has been mapping through Lucee admin panel.
I searched this topic on the Lucee dev forum nothing remedy worked out. Can you please share the solution if you guys face this issue ever?
Thanks in Advance to heads up!!
Abhi
are you sure it’s Lucee throwing the 307?
the only place lucee issues a 307 is on the first request when it creates a context
you can change it to say 301 as per here to be sure
https://viviotech.github.io/mod_cfml/docs-valve.html
I’m using mod_cfml-valve_v1.1.05.jar and config is:
Valve className=“mod_cfml.core”
loggingEnabled=“false”
waitForContext=“5”
maxContexts=“200”
timeBetweenContexts=“2000”
scanClassPaths=“false”
sharedKey=“xxxx–changed–SK”
as per your suggestion just tried to add that response code line along with current settings neither 307 nor 301 is worked…
Do I need to install latest module 1.1.11 to get rid of this issue? 1.1.11 was throwing some issues that’s what I gone with 1.1.5.
but are you sure that the 307 is coming from mod_cfml Tomcat Valve?
if you restart tomcat and open the “http://ft.com/test.html” url does it happen? if it does, I think it’s not a mod_cfml problem
because mod_cfml only kicks in once it sees a cfml or cfc in the url
@Zackster
Thanks a lot for your reply!
I agreed that html shouldn’t be kicks in by Tomcat valve so I replaced html to a sample cfm file and restart tomcat with and without response code which is throwing the same output.
test.cfm file content
cfset firstName = “World”>
Hello #firstName#!
This CFML tutorial was designed for
<cfif firstName eq “World”>
you!
the world to see.
I’ve no experience with ngnix, but just to give a shot into the dark… I had a very similar issue with 307 redirects and they looked a lot like yours. The issue was chrome redirecting to https without any interference at all of the server. Chrome had an internal directive that forced https, and marked it as an 307 internal redirect in th e network tab. It really looked very similar to yours. But in my case it was because of an HSTS strict transport server header that was set somewhere in the past browser history. Your “non-authoritative-reason” looks different then mine, but I’d bet its a similar issue.
What I’d try in your situation is make a requests without a browser, just to rule out that internal browser behaviour, forcing https to your ft.com by itself.
Update: besides of what I’ve said, you are requesting a page from ft.com. You might have set it up locally in your etc file as a local IP of your network, but that domain belongs to The Financial Times. Maybe Chrome is just doing a security directive set by the real issuer of ft.com. Also, the real domain webserver sends a response header of Strict-Transport-Security: max-age=63072000; added with the preload directive. if you’ve visited the real ft.com with your browser before you’ve set up that domain to point to your own ip, I bet that HSTS directive will still be valid in your browser, creating such 307 redirects. Chrome may even have hardcoded the https to ft.com (see HSTS preload Try requesting your web application with another http tool (telnet, postman, curl or whatever) to rule that out.
Update 2: ft.com has a preload status! See
1 Like
@andreas you awesome!!
The problem is HSTS on Chrome/Brave browser which is already hardcoded preload status. I tried with Mozilla after turn off “network.stricttransportsecurity.preloadlist” as false does works!!
Thanks a lot
Issue is resolved!
Abhilash S V
1 Like
