- Shipped
- August 8, 2026 at 3:19 AM UTC
- Author
- Kamo
- Commit
- dcc4af3
A 2 GiB chat attachment failed after nearly four minutes of successful transfer with MultipartException wrapping a bare SocketTimeoutException, and the member was told 'Internal Server Error'. Tomcat's disableUploadTimeout defaults to true, which does not mean there is no upload timeout — it means the separate, longer one is disabled and connectionTimeout governs body reads as well. That default is 60s and was never overridden, so any 60-second pause in an incoming body killed the request. At the old 100 MB ceiling a transfer rarely ran long enough to meet one; at 3 GiB it runs for minutes across browser, Traefik, the Next BFF and Tomcat, where a stall that long is close to inevitable. The body now gets an hour, matching the Traefik entrypoint in front of it, while the request line and headers keep the 60s deadline that actually bounds slowloris. Multipart parsing happens before a handler is chosen, so these failures never reached the controller's own error handling and fell through to Spring's blank 500 — the same response for a stalled connection and an oversized file. They now answer 408 and 413 with a reason a member can act on.