I have my custom 404 set in CFadmin, but Apache is catching any .html 404s I wonder if there is a way to have Apache send 404s to my Lucee custom 404?
So everything is uniform?
Don’t forget to tell us about your stack!
OS: Alma Linux 9
Java Version: 21.0.6
Tomcat Version: Apache Tomcat/10.1.39
Lucee Version: 6.2.0.231
Yes, in your apache conf, use:
ErrorDocument 404 /your404handler.cfm
More at Custom Error Responses - Apache HTTP Server Version 2.4
Note that if you dump the cgi scope or getthttprequestdata(), you should see the various extra headers documented there as being passed along by apache to such an error handler. They could come I’m handy.
Note also how it suggests that you set the 404 statuscode in your error handler, so that it’s returned to the caller, which you can do with cfheader statuscode=“404”, in script or as a tag. Many forget to do that, which keeps callers from knowing their request is mistaken, and smarter ones could eventually stop asking, so it’s worthwhile. (Then again, some browsers see a 404 and put up their own display. Grr.)
Finally, something to always beware with such a cfm doing 404 handing for your web server: it will likely be pounded by crap requests for files and file EXTENSIONS that previously the web server merely replied to and logged. Now your cf code will handling EVERY ONE OF THEM. Be careful especially about what code you run for each such requests in your application.cfc/cfm.
Consider also that a requester of a gif, jpg, css, js or other such file won’t ever see your nicely formatted html. (Same with a cfc request expecting json in return.) You may want to detect such a file extension (other than cfm, htm, or no extension) and quickly return a 404 and do nothing more.
Finally, consider also that if your application.cfd/cfm enables session management, then each such request from any sort of automated agent will create a new session, as it won’t return lucee/cf session cookies. Sure, that’s true of any request that previously got to the cfml engine–but you might open the door to exponentially more requests. Think about lowering the session timeout for such requests. It’s been written about amply in the cf community over the years.
Sometimes it’s little things like these which people never warn about when saying simply “sure, this is how easily you can setup your webs server to pass in 404’s to a cf page”. 
But yeah–as I said in the first sentence–it really is “that easy”.
Don’t be discouraged, though. Just be conscious.
Ah Ok, thanks. I had not considered that -= will investigate,
6.2 has some improvements with regards to how memory sessions are optimized, basically the same approach used for external storage is now used for internal memory sessions, the result being less memory being used for such empty memory sessions
On the related subject of advanced uses of 404 handling, I use it extensively for friendly urls aka web app endpoints. It’s analogous to Routing in Express for Node.js.
For example, instead of:
https://www.foo.com/buytix.cfm?event=123
The friendly url is:
https://www.foo.com/buytix/123
Then in my 404.cfm I parse the action (buytix) and event ID, then include the buytix.cfm template.
Over the years my 404.cfm has evolved to be way more complex than that example, but that’s the basics of it.
have you tried urlrewrite? that’s a better approach for SES urls
you just need to drop some config into tomcat/conf/web.xml
https://www.tuckey.org/urlrewrite/
v5 is for Tomcat 10+
There are pros and cons to each approach.
New versions of Tomcat and/or Java and various other specific use cases can introduce breaking changes for UrlRewriteFilter. And as there hasn’t been a commit in 2 years, no guarantee of quick fix. Sure it’s open source so I could hypothetically update it or even fork it myself, but that’s a whole lot more time and effort and simply not realistic.
The main advantage of my solution is zero dependencies. I know it’s a hack, but I’ve been using it since before UrlRewriteFilter existed with no discernible impact on performance. Also … I love hacks, especially when they’re mine. 