HTTP Long Polling - What it is and when to use it

Why we need HTTP long polling is all down to why the web was invented. It’s easy to forget now, but the original web was built by an academic as a way to publish and connect static documents. What made it

a success was that any document, or web page, could link to any other document. Unlike other systems, such as Gopher, the World Wide Web didn’t require a formal hierarchy. 

That freedom, and the resulting ability to surf through a web of links, sparked the imaginations of people outside academia. With time, the “web of documents” became home to the huge variety of interactive applications we have now.

But there was no JavaScript, there were no server-side scripting languages, and server CPUs ran in the low megahertz with RAM measured in megabytes. Web servers couldn’t handle persistent connections even if there was a use for them. So, the only job HTTP had was to ask a web server to return a web page located at a particular URL.

Contrast those static web pages with the rich software applications that run in today’s browsers. If you’ve ever driven down a rural road, then you’ve experienced something similar to the problem of meeting the modern web’s needs with HTTP alone. A single track lane that for thousands of years allowed a handful of carts and the occasional herd of livestock to move slowly from one place to another must now accommodate hundreds of SUVs, buses, and tractors each day. You can pave the road and add passing places but the strains of heavy traffic moving in both directions becomes quickly apparent.

That’s because both modern road traffic and web application traffic are two-way and frequent. Build a chat application and your users will expect messages to arrive the moment they’re sent

. But HTTP wasn’t designed for a world where servers send data to clients uninvited. 

Known as polling or short polling, early web applications would make repeated HTTP requests at timed intervals. Similar to answering your front door on the chance that someone is there, it’s not especially efficient. The overhead of parsing, responding to, and closing so many requests is both wasteful and hard to scale. That made web application scalability a particular challenge at a time before elastic cloud computing and modern application architectures.

HTTP long polling solves the problem of building bidirectional applications on the web - a platform designed for a one-way world where clients make requests and servers respond. This is achieved by turning the request-response model on its head:

1. Client sends a GET request to the server: Unlike a traditional HTTP request, you can think of this as open-ended. It isn’t asking for a particular response, but for any response when it is ready.

2. Time passes: HTTP timeouts are tunable using the Keep-Alive header. Long polling takes advantage of that by setting a very long or indefinite timeout period, so the request stays open even though the server doesn’t have an immediate response.

3. The server respond

   s: When the server has something to send, it closes the connection with a response. That could be a new chat message, an updated sports score, or a breaking news alert.

4. Client sends a new GET request and the cycle begins again.

Key to the success of HTTP long polling is that it does nothing to change the fundamentals, particularly on the client. Working within the web’s existing model, and using essentially the same infrastructure as the static web, long polling’s superpower is that it works almost everywhere. It’s also less wasteful. Although clients still open multiple HTTP requests, almost all of them result in data returned from the server.

However, it’s on the server that most of the work needs to happen. In particular, managing the state of potentially hundreds of thousands of connections is resource intensive. 

When it comes to enabling servers to push data to web clients, HTTP long polling is a workaround. It bends HTTP slightly out of shape to give us a widely available way to let web servers push data to web clients. But does it still make sense in a world where multiple, dedicated realtime protocols are available?

The short answer is that, yes, HTTP long polling still has a role to play - but more as a fallback in most scenarios. To understand where long polling can be useful, we should look at what it does well and where it falls short.

• Available in almost every web client: Because it uses the basic HTTP request-response cycle, just about every HTTP-enabled client (browser, library, IoT device, etc) that lets you tune the timeout and supports XMLHttpRequest already supports long polling.  

• Your web server already supports it: Although you’ll need to write your own code to handle how long polling works on your application’s backend, long polling works with existing web infrastructure.

• Not blocked by firewalls: Modern realtime protocols use different ports to HTTP and some use UDP rather than TCP. Although it’s much less of a problem than it used to be, some corporate firewalls might block those protocols but not HTTP.

• Inefficient and slow: Modern realtime protocols, such as WebSocket, incur much less overhead than long polling. They set up a single, persistent connection and send data as needed. Long polling requires a full HTTP handshake every time the server sends something to the client. That wastes bandwidth and increases latency.

• Somewhat complicated to scale: Long polling’s status as a workaround becomes clearer the more we ask it to do. Scaling long polling across multiple servers means keeping track of session state in a fundamentally stateless protocol. One option is to use a third-party data store such as Redis and to reload that state with each new HTTP request. Another is to implement sticky sessions, so the same server handles the same client each time. That brings additional complexity, as you’ll need a strategy to ensure load is distributed evenly across your cluster. Another potential issue is that there’s no built-in way to avoid overwhelming your server resources. As such, you’ll need to create your own back pressure mechanisms to monitor server load and adjust the rate of inbound requests, for example by delaying or temporarily rejecting connections.

• Hard to make guarantees: It’s hard to guarantee that messages will arrive from the server to the client in order or at all. For example, if a client has two browser tabs open consuming the same server resource, and the client-side application is persisting data to a local store such as localStorage or IndexedDb, there is no in-built guarantee that duplicate data won’t be written more than once. This could also happen if the client implementation uses more than one connection at a time, whether deliberately or as a result of a bug in the code. Similarly, a server could send a response but network or browser issues may prevent the message from being successfully received. Without extensive tracking code on both your clients and your server, there’s no way to keep track.

HTTP long polling probably isn’t going to be your first choice for building realtime communication into your applications. However, it still has an important role to play, even if something like WebSocket is more likely to be your first choice. Let’s recap why:

• It’s just HTTP: You don’t need any special libraries on either the client or your server. Even very old clients should support long polling. In rare cases where network restrictions make WebSocket and others unviable, HTTP is almost certainly available.

• It can be easy to implement: So long as your needs are relatively modest, long polling doesn’t ask all that much of you. And there are libraries for all major languages, such as Polymer for NodeJS.

• It gives you an easy on-ramp to realtime: You can experiment with realtime features in your application without making a large investment in adopting an entirely new technology.

With all that in mind, when should you use HTTP long polling? Here are a few situations where it is a good option:

• As a fallback: HTTP long polling’s main role is as a backup for situations where client or network limitations mean a dedicated realtime protocol is unavailable.

• For small scale projects with limited realtime needs: If latency isn’t a concern and you don’t expect realtime features ever to be a large part of your application, you might consider long polling as it could require less effort compared to learning and implementing a newer method.

• For prototyping: Similarly, when you’re trying ideas out, long polling gives you a scrappy way to sketch a solution while limiting the number of dependencies you introduce.

For a technology that is almost 30 years old, long polling is still playing a useful role in how we build web applications. However, as we’ve seen, it’s probably better suited as a backup option because we have a number of dedicated realtime technologies to choose from. Like every tool, each one has its own pros and cons. So, let’s take a brief look at what you might use instead of HTTP long polling.

HTTP long polling has its place - but more modern approaches that overcome its downsides (primarily latency and difficult scaling) are available. So, we should think of HTTP long polling as one tool amongst many. 

But realtime communication isn’t only about choosing the right protocol. You also need the infrastructure to back it up. 

Although you can build your own, there are significant risks. Designing, building, and maintaining realtime infrastructure will redirect your engineering capacity away from working on your product’s core features. Our research shows that 41% of in-house realtime infrastructure projects miss deadlines. That can mean delays in getting to market, as well as the need to hone specialized engineering skills. Instead, you might want to consider a realtime platform as a service, such as Ably.

Our reliable, low latency, realtime platform as a service (PaaS) lets you choose the right method for your use case, whether that’s HTTP long polling, WebSocket, MQTT, Server Sent Events, or something else. Just as importantly, Ably’s global infrastructure takes that particular DevOps burden off your hands. You can focus on building your application and take advantage of:

• A global edge network: Wherever your app’s users are in the world, Ably edge locations ensure less than 65 ms latency right across our network. In

• Not only WebSocket: Ably selects the right protocol for your application’s needs and network conditions, choosing from options such as WebSocket, Server Sent Events, and MQTT. 

• Resilient delivery: Ably guarantees that messages arrive in order and on time.

• 99.999% uptime: Ably’s network routes around failure to ensure your application keeps on delivering.

• Scale to meet demand: As demand grows, Ably scales from thousands to billions of messages.

• Great developer experience whatever your tech stack: With SDKs for more than 25 languages and frameworks, integrations with common tooling, and industry leading documentation, Ably gives you the tools to become productive quickly.

Sign up for your free Ably account and start building today.