What is the difference between HTTP streaming and server sent events?

Question

My understanding is that HTTP streaming involves the client sending an HTTP request and then response to the request being sent over time allowing the server to essentially push to the client. In what I have read it seems that SSEs operates along the same principle but, is more formalized. Is that close to a correct understanding?

I saw these questions but they didn't really answer my question directly.

HTTP: what are the relations between pipelining, keep-alive and Server Sent Events? What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?

I also looked at this https://www.html5rocks.com/en/tutorials/eventsource/basics/#disqus_thread tutorial for setting up SSEs and it seems like how I would imagine HTTP streaming is set up.

Answer 1

SSE is in fact a form of HTTP streaming. It is just an HTTP response with MIME type of "text/event-stream" and it sends plain text messages terminated with double newlines.

SSE is not something that was impossible to do before, but the website had to use WebSocket connection, AJAX long polling, comet, periodical polling etc. and now with SSE the API is standardized and the implementation is very simple. See:

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

One of the things to keep in mind is that SSE is not supported on IE including Edge and IE Mobile:

• http://caniuse.com/#feat=eventsource

So you cannot really use it for wider audience (yet), unless you know what browser they use.

Answer 2

IMHO, HTTP2 Server sent events has rich features than HTTP Streaming.

In a unidirectional data flow (Server -> Client) where client side could be orchestrated based on backend events, server sent events could be a good choice.

For example:

# ---------- client side -----------

const eventSource = new EventSource("//your-api/workflow/state");

eventSource.addEventListener("queued", function(event) {
    ...
}
eventSource.addEventListener("started", function(event) {
    ...
}
eventSource.addEventListener("failed", function(event) {
    ...
}
eventSource.addEventListener("success", function(event) {
    ...
}

Limitations of Server sent events:

• SSE events consume browser open connections.
• There is a limit on number of max open connections not at browser tab level but whole browser level
• The time I am writing, Chrome & Firefox has it as 6 (too low). This limit is per browser + domain, so that means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com.

HTTP Streaming

There are many use cases where HTTP streaming could be useful. If we are only interested in a stream of message from Server, this could be handy.

Example scenario :

Let's say we like to stream a log file content to client. Either it could be a huge file or the file content keeps updating and we like to send it to client (like a log tail). In such case, HTTP stream (Transfer-Encoding: chunked) could satisfy our needs.

# ---------- client side -----------
const streamRequest = (url) => {
    fetch(url).then(function (response) {
        let reader = response.body.getReader();
        let decoder = new TextDecoder();
        return readData();
        function readData() {
            return reader.read().then(function ({value, done}) {
                console.log(value)
                if (value) {
                    let newData = decoder.decode(value, {stream: !done});
                    console.log(newData);    
                }
                if (done) {
                    console.log('end of stream');
                    return;
                }
                return readData();
            });
        }
    });
}

Limitations of Stream response:

• In case of stream response (chunked) - HTTP/2 doesn't support HTTP 1.1's chunked transfer encoding mechanism, as it provides its own, more efficient, mechanisms for data streaming.