While this SSE channel stays open, the controlling app will need to be able to continue to do additional traditional GET, POST, etc. calls to the server. How are responses to those distinguished from data coming in from SSE?
> Each HTTP connection maps to one underlying transport connection.
-- https://httpwg.org/http-core/draft-ietf-httpbis-messaging-la...
TCP uses "port numbers" to identify different connections. 2 different connections from your PC to the same web server will use 2 different "source" ports. A port is just a number in the TCP header. https://en.wikipedia.org/wiki/Transmission_Control_Protocol#...
HTTP/1.1 added pipelining, so you can make several requests on the same TCP connection before receiving a response. But the (complete) responses must arrive in the same order of the requests so it doesn't work for SSE.
HTTP/2 added request & response multiplexing on the same TCP connection. But (according to the OP) there are some limitations that affect SSE.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
This works like SSE, but is designed specifically to articulate changes to the state of HTTP/REST resources.
If you're in Javascript, you can use the braidify library: https://www.npmjs.com/package/braidify
I was considering Websockets or MQTT (or both), so server-sent events sound like a direct and possibly superior competitor. But from a design standpoint, what do you do? Just do a GET on some general "status" endpoint to open this SSE stream and then have the server send everything down this pipe indefinitely?