Apache 2.4 RewriteRule to 404.cfm displaying code instead of executing

dev support
1

The following .htaccess has been working perfectly 10+ years on my CentOS production server currently running Apache 2.4, the purpose being to process user/seo-friendly urls, but on my new dev laptop running Ubuntu 20.10 and the same Apache 2.4, the 404.cfm contents are displayed in the browser as plain text instead of the Lucee script being executed.

When I try ErrorDocument 404 /404.cfm instead of RewriteRule, 404.cfm executes, but it’s not able to access the original url because cgi.request_url has been changed to the 404.cfm.

What am I missing?

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !.cfm$
RewriteCond %{QUERY_STRING} !=“”
RewriteRule ^(.*)$ 404.cfm?404;http://%{HTTP_HOST}%{REQUEST_URI}?%{QUERY_STRING}

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !.cfm$
RewriteRule ^(.*)$ 404.cfm?404;http://%{HTTP_HOST}%{REQUEST_URI}

OS: Ubuntu 20.10
Java Version: 11.0.6
Tomcat Version: 9.0.31
Lucee Version: 5.3.7.48

2

Can you check in your logs of apache2 and Tomcat how apache2 is passing this request to Lucee? I wonder if Lucee is sending the file as plain text or apache2 is interpreting your 404.cfm as a static file. And what happens if you fire the same rewrited request from your browser directly?

1 Like
3

After digging deeper in the Apache 2.4 docs I found:

“From 2.4.13, expression syntax can be used inside the directive to produce dynamic strings and URLs.”

Therefore, and realizing that I have no need for query strings in user/seo friendly urls, the solution is now much simpler than RewriteRule:

ErrorDocument 404 /404.cfm?%{REQUEST_URI}

Voila!

1 Like