I was thinking it would be something that would be left on in a live system. We can set these parameters, so it would be useful to know if we were hitting the set limits.
I'm not sure I fully grasp how this additional logging presents a significant incremental DOS risk. I mean, if an attacker is flooding you with enough traffic or connections where this becomes an issue, aren't you already logging various aspects of the attempts anyway (e.g., access logs, etc)? At that point aren't your logs already being filled anyway? On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Baron, > > On 4/9/24 16:33, Baron Fujimoto wrote: > > I'm investigating occasional 503 errors for our CAS service running in a > > Tomcat 10.1.x container. The 503s appear to correlate with some traffic > > spikes at the same time. > > > > The connector is configured as follows: > > > > <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" > > port="8443" > > maxThreads="2500" > > maxConnections="50000" > > maxPostSize="100000" > > maxParameterCount="1000" > > scheme="https" secure="true" > > SSLEnabled="true" > > > > > > > Can Tomcat log info such as when the maxThreads or maxConnections limits > > are reached? I'm basically trying to see if there is a good way to > > more definitively determine what may have caused the 503s and what may be > > feasible to mitigate them. > > Are you thinking of a debugging feature or something to be left-on for a > live production system? > > Such logging might be considered a DOS vector for a live system: you can > fill the logs by asking lots of trivial requests. > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Baron Fujimoto <ba...@hawaii.edu> ::: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
