Hello, This is probably a question that would be better suited for the dev list, but I thought I'd start here first.
Does anyone understand the reasoning behind why Tomcat, when clustered, throws an HTTP status 404 and not a 503 when you have an application deployed but stopped or paused? What's confusing to me is why the Tomcat developers felt a 404 was an appropriate response even when Tomcat is clustered. It seems to me that a 503 would be more appropriate when Tomcat is clustered for several reasons. 1) When Tomcat is clustered, and you only have an application stopped or paused on one of the clustered nodes, it doesn't mean the request is truly unavailable; it just needs to be retried on a node where the application is running. 2) Since it's throwing a 404, that means if you don't want a stopped or paused app to cause the clustered application to become unavailable, you have to configure mod_jk fail_on_status to failover for 404s. 3) Lastly, configuring mod_jk to failover for 404s means you will never throw a 404 even when all apps are started, but a page really doesn't exist. 4) It seems to fail over for every 404 would make it very easy to create a DOS attack causing mod_jk to thrash by simply making lots of requests for pages you know don't exist. Anyways, just wondering if anyone out there understands why the decision was made that a 404 was still the appropriate status code to throw even when Tomcat is clustered. I think I understand that my only option is to failover for 404s considering the current implementation. I've looked to see if there was a configuration setting related to clustering that would allow me to change the behavior, and I couldn't find one; the only solution seems to be to write a custom listener that detects that an application is deployed but stopped or paused, and then throw a 503 instead. I asked ChatPGT what it thought about all this, and here is what it had to say... *"Your points are absolutely valid and they highlight some of the challenges with using a 404 status for situations where a web application is stopped or paused in a clustered environment. A 503 status would indeed be more semantically appropriate in these situations as it more accurately indicates that the service is temporarily unavailable rather than the resource being not found.* *1) As you correctly pointed out, in a clustered environment, a stopped or paused application on one node does not necessarily mean that the requested resource is not available. It could simply be that the resource needs to be requested from a different node where the application is running.2) Configuring `mod_jk` to failover on 404 errors can help in these situations, but it comes with the drawback of treating all 404 errors as potential failover triggers, which may not always be appropriate or efficient.3) If `mod_jk` is configured to failover on 404 errors, then, as you mentioned, a true 404 error (where a page really does not exist across all nodes) would not be surfaced to the client. Instead, `mod_jk` would keep trying to find a node that can handle the request, potentially wasting resources.4) Lastly, you're right that this setup could potentially be exploited for a denial of service (DoS) attack. An attacker could generate a large number of requests for non-existent pages, causing `mod_jk` to constantly attempt failovers and use up system resources.In an ideal world, Tomcat would provide a more nuanced way to differentiate between these scenarios and return a 503 status when an application is stopped or paused, especially in a clustered environment. However, as of my knowledge cutoff in September 2021, this is not the case. I'm not aware of the specific reasons why the Tomcat developers chose to use a 404 status for these situations, but it's possible that it was a simpler option to implement and it met the needs of most users at the time.The custom Valve solution discussed earlier could potentially help address these challenges by allowing you to control the error status that Tomcat returns based on the specific state of the application and server. But this does require additional custom development and testing.This is certainly an interesting topic, and I appreciate your insights. Let me know if you have any further questions or thoughts!"* -- Thanks, Dan -- *NOTICE:* This e-mail message and all attachments transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is strictly prohibited. The contents of this e-mail are confidential and may be subject to work product privileges. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
