How do short polling and long polling differ in what the HTTP server does with each request for updates?

Long before any protocol let a server speak first on its own initiative, applications faked live updates with ordinary HTTP requests. Two shapes emerged. They use the same exchange, the same fields and the same status line, and they differ in exactly one place: **who waits**. ## Short polling: the client waits The client asks on a fixed timer — every five seconds, every minute — and the server answers **immediately**, whether or not there is anything new. An empty answer is a normal answer: a status line, the response fields, and a body that says there is nothing. - The only clock that matters is the client's interval. - Worst-case freshness is one full interval plus a round trip: an update published the instant after a poll waits for the next one. - On a workload that changes rarely, nearly every request is wasted work that still pays the full price of an exchange in both directions. - Nothing about the exchange is unusual, which is the point — every intermediary, cache, log and client on the path already understands it. ## Long polling: the server waits The client sends the same kind of request, but the server does **not** answer an empty result straight away. It parks the request, registering it as interested in a channel, and returns only when an update is published or its own bounded hold period expires. On receiving any response at all, the client issues the next request immediately. 1. The client sends a request carrying the position it has already consumed. 2. The server checks for anything published after that position; if there is something, it answers at once. 3. If there is nothing, it holds the request, up to a hold period that is commonly tens of seconds. 4. On a publish it answers with what it has; on hold expiry it answers with an empty result. 5. The client processes the response and re-issues immediately. The cycle repeats. The latency win is real: an update published while a request is parked goes out roughly one network hop later rather than waiting for a timer. The cost is that the server now holds state for every idle client — the parked request, its channel registration, and whatever runtime resource the request occupies. ## Side by side | | short polling | long polling | |---|---|---| | who waits | the client, on its own timer | the server, holding the request | | answer when nothing is new | immediate and empty | delayed until the hold period expires, then empty | | freshness | up to one interval late | about one round trip after publication | | requests while idle | clients divided by interval | clients divided by hold period | | server state per idle client | none between polls | one parked request | ## What long polling does not change This is where candidates over-claim. Long polling is not a persistent channel; it is a sequence of ordinary requests with a delayed answer. - **One response per request, always.** The server cannot send a second update down a response it has already completed. The next update needs the next request. - **There is a gap.** Between the response landing and the next request arriving, nothing of that client's is open on the server, and anything published in that window has to be retained somewhere or it is gone. - **The per-exchange overhead is still paid.** Every cycle carries a request line, the client's whole field set, a status line and response fields — just less often than a short poll on a tight interval. - **The client's immediate re-issue is not a retry.** It is the normal cycle; treating it as error recovery leads to backing away from perfectly healthy empty answers. ## Where the names come from The family of techniques was called **Comet** in the mid-2000s, as a label for making a web page look live over a protocol that had no way of doing so. `RFC 6202` is the document that surveys the field and gives the two techniques their standard names: **HTTP Long Polling**, the shape described above, and **HTTP Streaming**, in which the server keeps one response body open and writes into it repeatedly. Two protocol families of that era, **Bayeux** and **BOSH**, were built on those transports — the first a general publish/subscribe protocol carried over HTTP, the second a way of carrying an always-on messaging session over it. The lineage matters for one practical reason: these are still the techniques you fall back to when something on the path refuses to carry anything more exotic.