fix(http): enforce absolute read header timeout against slow HTTP DoS

[Vonng]

Fixes #183

Root cause

A slow HTTP DoS scanner holds connections open by dribbling request bytes (slowloris). Two inherited gaps allowed exactly that:

1. deadlineconn neutralized the absolute header deadline. httpListener.Accept() wrapped every accepted connection with deadlineconn.WithReadDeadline(idle), which re-extends the read deadline on every partial read. net/http sets ReadHeaderTimeout as an absolute deadline (headers must complete within N seconds in total), but the wrapper converted it into an inter-byte activity timeout — a client sending 1 byte every 25 s keeps the connection (goroutine + fd) alive forever.
2. the timeout was never actually configured. The --read-header-timeout flag (default 30 s) is defined but never copied into globalServerCtxt in common-main.go, so the server ran with ReadHeaderTimeout = 0, i.e. disabled. Upstream MinIO master shares both defects (verified against minio/minio@master).

Fix

• internal/http/listener.go: keep deadlineconn on the write side only. Write deadlines stay activity-based (big downloads must not be capped in total), and native read deadlines are honored again.
• cmd/common-main.go: wire --read-header-timeout into the server context.
• cmd/server-main.go: drop UseReadTimeout. With native read deadlines honored, an absolute ReadTimeout would cap the whole request including large uploads; request bodies are bounded per-read instead (next point). WriteTimeout stays: it only resets the activity-based write deadline per request.
• internal/http/server.go: wrap request bodies in idleTimeoutBody, which refreshes the connection read deadline ahead of every body read via http.NewResponseController. Stalled uploads are cut off after the idle timeout while progressing ones extend indefinitely. Under HTTP/2 the controller is supported natively per stream; on hijacked connections it is a no-op.

HTTP/2 audit: x/net/http2 only sets zero (infinite) read deadlines on the conn, and Server.IdleTimeout is wired into the http2 idle timer, so idle h2 connections are still cleaned up after 30 s — no regression from dropping the read-side wrapper.

Verification

Unit tests (internal/http/server-deadline_test.go, full xhttp stack incl. listener and TCPOptions wiring):

• slow-header trickle killed at ReadHeaderTimeout — verified the test fails on the old listener code (connection survives) and passes with the fix
• stalled request body cut off at the idle deadline, handler observes the error
• slow-but-progressing body (4× the idle timeout in total) completes

Live single-node run (default flags):

probe	before	after
slowloris, 1 partial header / 3 s	alive ≥ 90 s (unbounded)	cut at 33 s
2 MiB PUT, 64 KiB chunks 1 s apart (32 s total)	ok	ok (no absolute body cap)
PUT stalled mid-body	~30 s cleanup	30 s cleanup (idleTimeoutBody)
GET with stalled reader (70 s)	~30 s write cutoff	~30 s write cutoff (unchanged)
regular mcli mb/cp/cat/stat	ok	ok

Regression: go build ./..., go vet, ./internal/http ./internal/deadlineconn suites, and the full ./cmd suite (720 s) all pass.

Residual: deliberate slow-body/slow-read trickle (inter-byte gap < idle) still holds a connection, as before — an object store cannot cap total transfer time without breaking legitimate large/slow uploads. Perimeter timeouts (LB/reverse proxy) remain the recommendation for strict environments; this change closes the unbounded slow-header case the scanner flagged.

[Vonng]

The request-header timeout fix has landed through PR #196, merged as 40220bd836cb. This alternative implementation is closed as superseded; its branch is retained.

The merged implementation preserves the absolute header deadline, wires --read-header-timeout / MINIO_READ_HEADER_TIMEOUT, and retains rolling idle timeouts for active HTTP/1 transfers. See the integration and validation record and the published documentation on timeout behavior and release status. Issue #183 now points to the merged fix.

As of September 16, these changes are on main but are not included in Server RELEASE.2026-09-03T13-18-01Z. Final release acceptance remains #203.