HTTP is stateless; sessions are a kludge of caching grafted on via cookies — and that kludge is the most vulnerable point of a server-side web app. The core attack is trivial: pick a deep link and request it repeatedly **without sending cookies**, dropping the socket immediately. Each cookieless request creates a *new* session (several KB each), and the web server never tells the app server the client stopped listening. "Even a desktop machine on a broadband connection can generate hundreds of thousands of sessions." Real-world triggers include misconfigured proxies replaying a URL, and an interceptor that treated each cookieless request as a fresh login — 100,000 transactions updating the same profile row deadlocked the database and used up every request-handling thread. The hostile version: **screen scrapers / competitive-intelligence leeches** ("a battalion of people with clipboards") and **DDoS botnets** that saturate your outbound bandwidth and rack up huge charges. `robots.txt` is only a social convention; the leeches ignore it. What works: **block offending hosts/subnets** (itself "a form of Circuit Breaker," expiring old blocks), legal terms of use, and running DDoS-mitigation gear in *baseline mode* for a month first. Minimize per-session memory so you can purge under pressure. --- *Source: [[Release It Second Edition]] (Michael T. Nygard, Pragmatic Bookshelf 2018) — Ch 4 — Stability Antipatterns*