XHR streaming closes connection by design?

Question

I was reading this article: http://blog.pusher.com/what-came-before-websockets/, and the following text gets my attention:

XHR Streaming worked in all browsers the responseText of the XMLHttpRequest object would continue to grow until the connection was closed meaning a reconnection had to eventually be forced to clear this buffer.

If I understand this correctly, does this mean that whenever the buffer reaches certain size (what is the actual size here, by the way?), the connection will reset itself to clear up this buffer? In other words, XHR streaming is as long living as the size of this buffer?

Can someone please confirm this.

Answer 1

XMLHttpRequest is not designed to be used in a streaming fashion. As long as the server sends more data, the browser will continue appending it to the responseText field in the XHR object.

Therefore, I'm pretty sure that what they meant is that the JS code using XHR for streaming would have to periodically drop the connection and open a new one — or else leak memory due to keeping all data ever received, as well as wasting time reallocating a forever-growing string.

That is, the limitation is one you must implement in order to have acceptable long-run performance, not one imposed by the browser. (There may well be also a browser-imposed cap on response size, but I don't know if there is.)

Answer 2

In practice the connection will close much earlier as web servers, front end load balancers and ISP proxies will have maximum lifetime for any connections. If you want to use this with mobile browser you have to use SSL, otherwise mobile operators proxies will buffer the data and you will not get streaming but whole response when connection terminates.

Browsers have internal maximum size for the cumulated body text, but this is high so you are not likely to hit it. In this case xhr request raises error and terminates.

Implement your code with robust retry logic. I recommended using HTML5 EventSource instead of doing this with plain XHR. You can also google up some SHIM api wrappers for EventSource as example how to do streaming with XHR.

Answer 3

Streaming is an extension of XHR, which allows you to retrieve pieces of the data as it comes in. Otherwise you'd have to wait until the entire message was received. Regardless, it still has a buffer to fill. In practice it only works with a few browsers. Web sockets are usually a better option anyway.

With regular XHR you can have a long-polling request where the server doesn't send anything until it has something to send. When something is received you can have the client re-initiate the request. Under optimal conditions you can keep that request going on forever, but you can't guarantee that something in-between won't kill the connection. So with a long-poll you typically want to have the server send a heartbeat after a certain amount of time to force the client to renew the connection (like 5 minutes).