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.

Alius

Yikes! If true, this is crazy. – Bromism

This absolutely makes sense; web sockets might be better suited for the purpose of long standing connections. – Anatol

you can always modify the header to have Connection: close – Stinkweed

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.)

Contemporize

A memory leak isn't the right term here; we all know where the memory is allocated :) – Anatol

@Jack I disagree; specifically, I say that a memory leak is any case where memory containing no-longer-used data is not eventually freed (and I think such folks as garbage-collector implementors would agree). Your definition is either subjective ("if it's not obvious, it's a leak") or implies that garbage-collected programs do not contain leaks by definition. (I hope this clarifies my meaning; I don't plan to actually argue-over-definitions-of-words.) – Contemporize

seems to me we need a term for unbounded memory consumption produced by code that's perfectly valid, but still completely insane :) – Meuse

@KevinReid, hey I thought I allocated 100 points for the answer, why you only got 50 awarded?! – Alius

@Alius You did not choose an answer to award the bounty to, so half the value was automatically awarded based on votes. – Contemporize

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.

Decapitate

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).

Threepiece