a single 404 request generates the following large log entry (3,384 bytes) , the stack trace is redundant
also why is there no timestamp?
Lucee makes no difference between that log entry and every other. log entries never care if the data provided are redundant with other entries, that is how log entries work, we cannot simply change that fact. sure we could do a appender that has this additional logic, for example a datasource appender that keeps the stacktrace in a different table. But an improvement like this cannot be part of this ticket, we would need a feature request ticket for that and do this as part of moving to log4j 2.
What can we do?
change the log level to warning for 404, so log level error does ignore it
limit the stacktrace to the part within Lucee, we do not care about the application server part.
change the stacktrace to the following (only shrinked when no “caused by” present)
before it was
That's still debug level logging for production
i don’t think we can go below “warning“, it is still an exception after all
I still don't think it's appropriate to have a stack trace at all in this case. It adds no value. If a bot is hammering your site guessing .cfm file paths, there's no need to have a stack trace- just a single line in the logs with the timestamp that shows the path that was 404.
Question-- is this error caught and logged inside of Lucee or does it bubble all the way up to the servlet container? Perhaps a custom exception type can be used that bypasses normal error logging? The exception class is MissingIncludeException but that doesn't seem to differentiate between an include specified in code via the cfinclude tag and a path coming from an HTTP request URL.