What is Long Polling?
Also called HTTP Long Polling.
Long polling is a technique in which a client sends an HTTP request and the server intentionally holds it open until new data is available or a timeout expires. The client then immediately issues another request. It approximates server push using only ordinary request and response semantics, and predates widely available streaming transports.
Plain polling asks repeatedly on a fixed interval, which wastes requests when nothing has changed and adds latency equal to half the interval on average. Long polling inverts the wait: the server parks the request and responds the moment an event occurs. The client sees near immediate delivery while still using nothing more exotic than a normal HTTP call.
Correctness depends on a cursor. Because there is a gap between one response returning and the next request arriving, the client must tell the server where it left off, usually with a sequence number or timestamp. Without that, events produced during the gap are lost. Servers therefore buffer recent events long enough to serve a reconnecting client.
The resource profile is the main drawback. Every waiting client occupies a connection and, on traditional threaded servers, a worker, so scaling requires asynchronous request handling. Intermediaries such as load balancers and proxies must be configured with generous idle timeouts, and the server should return an empty response before those timeouts fire rather than letting the connection be cut.
Long polling remains useful as a compatibility fallback where WebSocket or Server-Sent Events connections are blocked by restrictive networks, and as a simple way for an automated client to wait on a job result without a dedicated streaming stack.
Key points
- Server holds the request open until an event or timeout
- Client must pass a cursor to avoid missing events
- Each waiting client occupies a connection
- Needs async servers and tuned proxy timeouts
- Still valuable as a fallback in restrictive networks
In practice
A client requests updates for a task queue, passing the last event identifier it saw. The server finds nothing newer and holds the request. Twelve seconds later a job finishes; the server responds instantly with that event and its new identifier. The client processes it and immediately reopens the request with the updated identifier. If nothing happens within thirty seconds, the server returns an empty result and the loop continues.