<div dir="ltr"><div>Hello,</div><div><br></div><div>My optimised and heavily-cached OpenGrok-based dev web site has finally succumbed to the DDoS from the supposed AI abuse, so, I'm, reevaluating resource usage and the applicable limits.</div><div><br></div><div>My objective is to serve everyone as long as there is available capacity.  Instead of doing a cat and mouse game on blocking any specific identifier, like User-Agent or IP or netblock or region, I want to block excessive usage IFF the content isn't already cached.</div><div><br></div><div>For example, the search results page on my OpenGrok may take 10ms to 50ms to generate when the Lucene index is stored on an mfs, but once generated, the page is basically "free" to serve, and I want keep serving the cached entry even during what may look like a DDoS attack on my instance.  Otherwise, a Slashdot-like event could result in the most popular combination of identifiers being promptly blocked, and legitimate users being denied access, even when the content was actually "free" and wouldn't have required any excessive resources to generate and serve.</div><div><br></div><div>I've re-looked at <a href="http://freenginx.org/r/limit_req">http://freenginx.org/r/limit_req</a> and <a href="http://freenginx.org/r/limit_conn">http://freenginx.org/r/limit_conn</a>, but I don't see any way to exclude cached content from still getting subjected to the limits.</div><div><br></div><div>I think the standard route here may be to use an <a href="http://freenginx.org/r/error_page">http://freenginx.org/r/error_page</a> exception handler, to automatically handle the 503 errors thrown by limit_req and limit_conn, and continue serving the content if cached, but I'm not quite certain how to integrate it with <a href="http://freenginx.org/r/proxy_cache">http://freenginx.org/r/proxy_cache</a>.  Any suggestions?</div><div><br></div><div>One option may be to use <a href="http://freenginx.org/r/proxy_store">http://freenginx.org/r/proxy_store</a> instead of proxy_cache, but I'm not sure that'll work properly when I'm also caching the search result pages, too, to account for the Slashdot-like events (they're currently referred to as "When many people access the same link simultaneously -- such as when a GitLab link is shared in a chat room"), without creating new restrictions on the input for the search query string, for example, not to mention having to do manual purges of the cached data and missing all the other nice features of the standard proxy_cache.</div><div><br></div><div>Best regards,</div><div>Constantine.<br></div></div>