Mark and Dan,
On 6/21/23 04:57, Mark Thomas wrote:
On 20/06/2023 17:12, Dan McLaughlin wrote:
Mark,
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?
http://home.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20Tomcat%20with%20mod_jk.pdf
Start on Slide 41
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
