Need all 404 errors handled the same, whether handled by tomcat or Lucee


#1

Hi All,

A previous thread got me thinking about how my app handles 404’s.

In our case, we want to treat requests to legit URL’s as normal. However, users can create customer subfolders that redirect to other urls, (ie bit.ly, tinyurl.com) or point to a homepage, etc.

To explain, let’s use the example of ‘domain.com/LuceeRocks’ which could be made to forward to the ‘how do we make lucee rock’ thread. Basic url redirection.

Currently, there wouldn’t be any physical resource at that URL. ‘LuceeRocks’ simply doesn’t exist. However, there’s a custom 404 error page script that grabs the ‘/LuceeRocks’ part of the originally requested url, and checks that against a list of redirects. If there’s a match, it grabs the destination url and sends the user off to that address.

The issue I’m hoping to address here is in my server setup, I’m having to create two custom 404 error entries. One for Tomcat and one for Lucee, and they both point to the same script.

The reasoning here is that Tomcat fields all the requests, and only passes on coldfusion based requests to Lucee. So when someone requests an invalid url such as ‘domain.com/LuceeRocks’, Lucee never sees it because Tomcat handles it first. The reason for the 2nd custom 404 error in Lucee is that in the case an invalid request is sent to Lucee, ie ‘domain.com/LuceeRocks.cfml’, it would then process the 404 the same way.

It seems better to let tomcat handle any request that doesn’t need to utilize Lucee. Such as a simple .gif request, or an .html file. And in the case either Tomcat or Lucee could potentially handle an invalid url, I need to configure each accordingly.

Thoughts? This is working for me, but I’m wondering if there isn’t a better approach as it’s been quite some time since this was all put together. Ultimately my question is if I can cut Tomcat out of handling all 404’s without adding more complexity vs two simple 404 entries in tomcat and lucee.


#2

I elected to simply use a custom 404 on both the webserver and application level. It works and anything more seems more complicated.

If I find a better solution, I’ll update this thread.