Long polling

Long polling turns an ordinary HTTP request into a waiting notification channel. A client sends a request for updates, and the server either replies immediately when data is ready or keeps the request pending until an event occurs or a limit is reached. After receiving a response, the client processes it and starts another request. The technique is therefore a repeated sequence of short-lived HTTP exchanges rather than a single connection that remains permanently open.

The server may return an empty or unchanged result when its waiting period expires, allowing the client to retry and preventing intermediaries from treating the connection as abandoned. HTTP defines request and response semantics but does not itself prescribe long polling; applications implement the pattern through their own endpoints, timeouts, and response formats.¹

A reliable implementation coordinates client retries, server timeouts, and event delivery. The client normally sends a request with an identifier or cursor, waits for a response, applies any returned events, advances that cursor, and reconnects after success, timeout, or a recoverable network error. The server should release pending requests when the client disconnects, and it must avoid sending the same event repeatedly unless the protocol deliberately supports replay.

Applications commonly carry data as JSON over HTTP, while status codes distinguish successful delivery, authorization failure, malformed input, and temporary service problems. Connection and request limits matter: a server may have many suspended requests consuming memory, file descriptors, worker capacity, or proxy resources. HTTP intermediaries can also impose shorter idle limits than the application expects, so heartbeat responses or conservative server-side timeouts may be needed.¹²

Long polling is useful when clients need prompt updates but the deployment environment supports ordinary HTTP more reliably than newer real-time transports. It has been used for notifications, collaborative interfaces, job-status changes, chat-like messaging, and monitoring dashboards. Compared with frequent polling, it reduces needless requests while no data is available; compared with a persistent bidirectional protocol, it can fit existing request-routing, authentication, and HTTP infrastructure.

Its costs are repeated headers, reconnection latency, and load concentrated in pending requests. It is not truly instantaneous, because delivery waits for the request to reach the server and for the response to traverse the network. It also provides no inherent message ordering, replay, authentication, or delivery guarantee; those properties belong to the application protocol. For sustained two-way communication, the WebSocket protocol is designed for a persistent connection, while Server-Sent Events provides a standardized one-way stream from server to browser.³⁴

Long polling is especially sensitive to edge behavior in shared infrastructure. A reverse proxy, load balancer, content filter, or mobile network may close an apparently idle request, buffer its response, or route successive requests to different servers. Distributed deployments therefore often need shared event state, sticky routing, or a durable cursor so that a reconnecting client can recover events without relying on one process's memory.

Backoff is another less visible design choice. Immediate retries after a server failure can create a reconnection storm, whereas bounded exponential backoff with jitter spreads load across clients. Servers must also cap waiting time, reject excessive outstanding subscriptions, and handle cancellation when browsers navigate away. Long polling can coexist with caching controls, but event responses generally need explicit directives such as Cache-Control: no-cache when stale intermediary responses would be harmful. These operational details often determine whether the pattern remains dependable at scale.¹⁵

Comet

A family of web techniques, including long polling, that deliver server-originated updates through browser-compatible HTTP interactions.

Pending request

An HTTP request that has reached the server but is being held until data is available or a timeout occurs.

Cursor

An application-level position or identifier that tells a server which events a client has already received.

Reconnection storm

A surge of simultaneous retries caused by many clients losing connections and reconnecting without backoff.