[undecuple]

Why

The status page server (-http) was started as a bare http.Server, with no timeouts. A connection that was slow to send its request, or stopped reading its answer, or sat idle, stayed open for as long as the client kept it, holding a goroutine and a file descriptor. The admin server already sets timeouts; the status page did not.

Change

• server/api.go: newStatusServer(addr, handler) builds the -http server with a 5 second header timeout, a 10 second read timeout, a 10 second write timeout and a 30 second idle timeout (named constants). The status answers are small, so these are far above a normal request.
• server/main.go: -http uses it.
• server/status_timeouts_test.go: the constructor sets the four timeouts to the constants and each is between 0 and a minute; a request header that is never finished and a connection that is idle after an answer are closed by the server (with short timeouts in the test), while a normal request is answered 200; main.go builds the status server only through the constructor.
• CHANGELOG Server: entry under Fixed; site/index.html and site/data.json regenerated (they carry the changelog).

Tests

• go vet, gofmt and go test ./server pass; python3 tools/repo_check.py, python3 tools/site.py --check, python3 tools/features.py --check and scripts/check-deploy.sh pass.
• Mutation-tested: dropping the header timeout from the constructor, setting the idle constant to 0, reverting main.go to a bare http.Server, and removing the idle timeout (with its override in the test) each fail a test. Against main, the new tests do not build, because newStatusServer does not exist there.

Not in this change

No new flag: the limits are fixed, as they are for the admin server. No header size limit, no change to what the pages answer, and the work the handlers do per request is unchanged.

Overlap

None open. Based on main at 7fdd762; touches CHANGELOG.md, server/api.go, server/main.go, the two generated site files and a new test file.

Developed with AI agent assistance.