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

*"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!"*





*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.

Reply via email to