skip to content

What does `server.tomcat.connection-timeout` control, and how does it help defend against slow clients?

level: seniorimportance: should knowfreq 40%

answer

  1. connectionTimeout connector attribute
  2. Boot default 20s (Tomcat bare 60s)
  3. wait for request line/headers after accept
  4. Slowloris / slow-client defense
  5. too low cuts slow mobile uploads; -1 disables

basics

~10 s

server.tomcat.connection-timeout (default 20s) is how long Tomcat waits after accepting a connection for the client to send the request line/headers. If the client is too slow, Tomcat closes the connection, freeing resources.

solid answer

~40 s

`server.tomcat.connection-timeout` maps to Tomcat's connector `connectionTimeout`. After a connection is accepted, Tomcat waits at most this long for the client to present the full request URI line (and effectively the header block) before timing out and closing the connection. The Spring Boot default is 20000 ms (20s). Its main value is defense against **slow-client / Slowloris-style** attacks and hung clients: without a bound, a client could open a connection, dribble bytes forever, and hold a connection/thread hostage, exhausting capacity. Setting it too low can prematurely cut legitimate slow networks or large uploads mid-transfer; note it primarily governs the wait for the request headers, not the whole request body or your handler's processing time (that's your own concern / async timeouts). It's one of several hardening knobs alongside `max-connections`, `accept-count`, and header-size limits.

code

yaml · 8 lines
yaml
server:
  tomcat:
    connection-timeout: 20s   # Spring Boot default; max wait for the request line/headers
    keep-alive-timeout: 60s   # idle time held between requests on a keep-alive connection
    max-connections: 8192
    accept-count: 100
# Lower connection-timeout to shed slow/hung clients faster (Slowloris defense);
# don't set it so low that legitimate high-latency clients get reset.

go deeper

for a junior

Knows it's a timeout on waiting for the client; may not know the exact default.

for a middle

Explains it bounds the request-header wait and the 20s Boot default.

for a senior

Frames it as Slowloris/slow-client defense and distinguishes it from processing timeouts.

for a principal

Combines it with max-connections/accept-count/header-size into a coherent connector hardening posture and reasons about client-latency tradeoffs.

## What it is `server.tomcat.connection-timeout` is Spring Boot's binding for Tomcat's connector attribute **`connectionTimeout`**. It is the maximum time Tomcat will wait, **after accepting a TCP connection**, for the client to send the request — specifically the request line and header block. - **Default in Spring Boot: 20000 ms (20 seconds).** (Tomcat's own bare default is 60s, but Boot sets 20s via `ServerProperties`.) - Accepts a `Duration`, so `20s`, `20000ms`, or `PT20S` all work. ## Why it exists — slow-client protection Consider a client that opens a connection and sends request bytes *one byte every few seconds*, never finishing the headers. Without a timeout, Tomcat keeps that connection (and, once dispatched, potentially a worker thread) occupied indefinitely. Enough such connections and you exhaust `max-connections` and/or the thread pool — this is the classic **Slowloris** denial-of-service. `connection-timeout` bounds that wait: if the request headers don't arrive in time, Tomcat closes the connection and reclaims the resource. ## What it does and does NOT cover - **Covers:** the idle wait for the initial request line/headers to arrive on an accepted (or keep-alive) connection. - **Does NOT cover:** the time your controller spends processing, nor necessarily the full slow streaming of a large request *body* — those are governed by other mechanisms (async request timeouts, `spring.mvc.async.request-timeout`, downstream client timeouts, `maxSwallowSize`, etc.). ## Gotchas - **Too low** → legitimate clients on high-latency mobile networks or sending large multipart uploads may be cut off mid-request; you'll see spurious connection resets. - **Too high / unlimited** → reopens the slow-client DoS window. A value of `-1` disables the timeout (never do this in production for public endpoints). - It's a *connector-level* setting, so it applies uniformly to all endpoints on that connector — you can't vary it per-route. - On keep-alive connections, the related `keep-alive-timeout` governs how long an idle connection is held **between** requests; `connection-timeout` is used as its default if keep-alive-timeout isn't set. ## When to tune Lower it (e.g. to a few seconds) for internal, low-latency services fronted by a fast load balancer to shed hung clients quickly. Keep it moderate for public internet clients on variable networks. Pair with `max-connections` and `accept-count` so slow clients can't monopolize capacity, and with `max-http-request-header-size` to bound header abuse.

  • Does connection-timeout limit how long my controller can take to produce a response?
    No. It bounds the wait for the incoming request line/headers after the connection is accepted. Handler processing time is governed elsewhere (e.g. async request timeout `spring.mvc.async.request-timeout`, or downstream client timeouts).
  • What attack does a sensible connection-timeout help mitigate?
    Slowloris-style slow-client denial of service, where a client opens many connections and sends request bytes extremely slowly to hold connections/threads open and exhaust the server's capacity.

saying these in an interview costs you the question

  • Thinking it caps total request processing time in the controller
  • Believing the Spring Boot default is 60s (it sets 20s)
  • Setting -1 (disabled) on a public endpoint
  • Assuming it protects against slow request *bodies* rather than the header wait

context

resolving links…