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.

Pia

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.

Brassie

not sure why you are being down-voted that sounds good to me. Thanks! – Pia

So in the end, whats the difference actually? This question doesn't answer that. If both are same(except the mime type header as you say), then what's the point of even introducing SSE when we already had http streaming? I feel like there is more to this question. – Samothrace

@Samothrace it's a standardization of what was before 'loosely defined'. It also introduced easier browser APIs to handle this. – Roberge

MDN says: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6) What can you say about this as of 2020? Is this limit still present? If yes, then we shouldn't use this technology in the first place and prefer things like WebSocket connections? What do you think? Thank you! – Muncy

@Muncy Still there is a limit on multiple tabs (6) when using SSE over non HTTP/2... – Ammieammine

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.

Fitful