Mark and Dan,

On 6/21/23 04:57, Mark Thomas wrote:
On 20/06/2023 17:12, Dan McLaughlin wrote:

What are your thoughts on changing the Tomcat codebase to return a 503
instead of a 404 if a context is marked as distributable or if
clustering is enabled and deployed but stopped?  When I did searches
years ago on this issue, most people at the time would recommend
adding 404 to the fail_on_status, which is what we did...until I
realized that we were causing our own internal DOS attack when we had
a 404 mistakenly left in our apps; that got me thinking how easy it
would be to make mod_jk thrash by just requesting pages that didn't
exist.   It's not a huge issue for us since most of our apps are
authenticated using SAML, so all requests are intercepted before the
request is ever sent to Tomcat, but for our apps that don't require
authentication, it would be easy to exploit any app that had 404 in
the fail_on_status.

I think the problem is the "STOPPED" state is used by different users for different things. Some want it to be equivalent to "The application isn't deployed" while others want it to be equivalent to "The application is present but currently under maintenance". I don't think we can safely infer which of those behaviors the user wants from the clustering and/or distributable settings.

I think the best solution is the "maintenance in progress" servlet deployed in the ROOT web application. Other options I considered:

1. New Lifecycle state "MAINTENANCE". This would be a significant change and I don't think the size of the problem justifies the scale of the changes required.

2. Extending/enhancing the "pause" feature. Not really the right place to start as pausing a context doesn't allow it to be updated (assuming updates are the main reason for the maintenance).

3. A per Host configuration option to set the status to be used for deployed but stopped web applications. Defaults to 404. Could be configured to be 503. Would require some changes to the mapper to add/remove contexts on deploy/undeploy rather than start/stop. Actually, this is a significant behavioural change since it changes the mapping. And the rewrite valve may complicate things further.

The more I think about this, the more nervous I get about changes like this introducing regressions.

I come back to the "maintenance in progress" servlet deployed in the ROOT web application. The one use case this doesn't cover is maintenance of the ROOT web application. Currently Tomcat is hard-coded to return a 404 if a request would be mapped to ROOT but that application isn't started. I think a request to make that status configurable would be implemented pretty quickly.

If you want to remove the node from the load-balancer, why not ... just do it? You can't test an application without it being deployed, and taking a node down for maintenance can (and IMHO) should include notifying the load-balancer that that node is coming down for maintenance. Otherwise, you'll bounce users off the node unnecessarily.

Since mod_jk is being used, why not simply change the state of the node-worker in mod_jk from ACTIVE to DISABLED (for testing, since requests with that node as a target will continue to go to it) or STOPPED (where mod_jk won't send any requests to it anymore?
Start on Slide 41


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to