Questions tagged [http-streaming]

Normally HTTP requests are used by a client to pull data from a server, which replies immediately. In order to discover data as soon as it becomes available using pull requests the client has to poll the server which introduces load on the server and high latency if the data is published between polling requests. An improvement on periodic polling is to use long poll or Comet mechanisms in which the server keeps the HTTP request open until there is data before sending it and closing the connection. HTTP streaming takes this approach one step further by keeping the connection open after the data is sent, allowing more data to be sent later. Both Comet and HTTP-streaming require web servers that can support many concurrent HTTP requests as all clients may be constantly connected.

HTTP streaming can be implemented in HTTP 1.0 by not returning a Content-Length header, which signals that the client should keep the connection open until it is closed by the server, rather than after a certain number of bytes have been read. HTTP 1.1 provides chunked encoding support which can also be used to implement HTTP streaming - the approach used by the Twitter streaming API.

As HTTP streaming requests may be held open indefinitely by the server it is often desirable for clients to be able to disconnect periodically in order to discard old data before reconnecting to the stream by making a new request.

HTTP streaming only allows unidirectional communication from the server to client and so is often combined with a traditional pull web API in order to allow bi-directional communication between client and server. If full duplex communication is required between client and server the emerging web sockets standards are a better choice.

For more information, see: http://softwareas.com/http-streaming-an-alternative-to-polling-the-server http://en.wikipedia.org/wiki/Push_technology