You can, but you should not depend on it. HTTP persistence only says the connection may be reused. Servers, proxies, load balancers and firewalls can close an idle connection at any time. For a nine hour session, send periodic traffic, enable TCP keepalive, and build reconnect and resume logic.
What does keep-alive actually promise?
Nothing about duration. RFC 9112 describes persistent connections in HTTP/1.1: by default a connection stays open after a response so the next request can reuse it, unless either side signals close. The same document says a server may close an idle connection at any time, and clients must be ready to retry safe requests when that happens.
Persistence saves the cost of repeated TCP and TLS setup. It is an optimisation, not a session guarantee. MDN's connection management guide makes the same point and notes that servers set their own idle timeouts.
Who closes an idle connection, and when?
Several parties along the path each keep their own timer.
- The web server or application server, with an idle or request timeout.
- A reverse proxy or load balancer, commonly with a default idle timeout measured in seconds or minutes.
- A network address translation device or stateful firewall that drops tracking entries for quiet flows.
- The client's operating system or library.
The shortest timer wins. You may configure your own server for nine hours and still lose the connection after a few minutes because a device you do not control gave up on it. Check the documentation of each hop for its idle limit, and raise it only where you own the setting.
What does TCP keepalive do, and why is it not enough?
TCP keepalive sends tiny probes on an idle connection to confirm the peer is still there and to keep state alive in middleboxes. RFC 1122 says keepalive is optional, off by default, and that if implemented the default idle interval before the first probe must be no less than two hours.
Two hours is longer than many middlebox timers. So you normally lower the interval on your sockets, for example to a minute or two, for connections you want to hold open. Even then, some hops only watch application data, and a probe may not count.
What works for long sessions?
Think in layers.
Application heartbeats. Send a small message every 30 to 60 seconds. For streaming responses, a comment line or empty event works. For WebSocket, use ping and pong frames. The traffic keeps every timer fresh.
Reconnect with resume. Assume the connection will drop. Give each session an identifier and let the client resume from the last event it received. This turns a dropped link into a short pause.
Use a protocol made for it. If your goal is server to client updates for hours, server sent events or WebSocket are designed for it. Long polling is the fallback.
Align timeouts. Make the client timeout longer than the heartbeat interval, and the server idle timeout longer than the heartbeat too, with margin for slow networks.
A constructed example
A back office tool uploads a large report and waits for a response while the server processes data for about nine hours. The request sits idle with no bytes moving. A load balancer with a one hour idle limit cuts it at 60 minutes, and the client sees a reset with no response.
A better design accepts the job, returns an identifier in under a second, and lets the client poll or subscribe for progress. If the status stream has a heartbeat every 30 seconds, no timer fires. If it drops anyway, the client reconnects with the identifier and loses nothing.
What about security?
Long lived connections hold resources and can be abused. Set per client connection limits, require authentication on the stream, and re-validate tokens on long sessions, since a token that expires in one hour should not authorise a stream open for nine. Idle timeouts are also a defence against slow connection exhaustion, so lengthening them everywhere is a trade, not a free fix.
How to check or apply this
- List every hop between client and server and note its idle timeout.
- Decide whether the work really needs one connection, or can become a job with status updates.
- Add application heartbeats at an interval well below the shortest timeout.
- Enable and tune TCP keepalive on sockets you control.
- Build resume support with a session identifier.
- Re-check authorisation on long sessions.
- Test by idling a connection in staging for longer than your shortest timer.
Quick check
Does the Keep-Alive header guarantee a timeout?
No. It carries hints, and the receiving side may ignore them. Treat any idle time as a request, not a contract.
Is a nine hour request a good design?
Rarely. A job identifier plus polling or streaming status is easier to operate and survives network changes.
Sources
Last reviewed: 18 October 2026.
