I had a similar issue at one point but if I remember correctly I just had to have my webserver send the header section without closing the connection.

Usually things would just get streamed through but for some reason until the full header was sent the proxy didn't forward and didn't acknowledge the connection.

Not saying that is your issue but definitely was mine.

Not entirely. If a load balancer is set to buffer say 4kb of data all the time, your SSE is stuck until you close the connection.

I think there is a HTTP/2 flush instruction, but no load balancer is obligated to handle it and your SSE library might not be flushing anyway.

In my case with this load balancer, I think it's just badly written. I think it is set to hold ALL data until the server ends the connection. I have tried leaving my SSE open to send over a few megabytes worth of data and the load balancer never forwarded it at all until I commanded the server to close the connection.

The dev who wrote that code probably didn't think too much about memory efficiency of proxying HTTP connections or case of streaming HTTP connections like SSE.

thanks, updated the article with your comment

> SSE works seamlessly with existing HTTP infrastructure:

To stress how important it is to correct this error, even Mozilla's introductory page on server-sent events displays prominently with a big red text box that server-sent events are broken when not used over HTTP/2 due to browser's hard limit on open connections.

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

Edit: I just saw the issue pointed out further down in the discussion

https://news.ycombinator.com/item?id=42511562

Yep, and in addition to that the ephemeral ports problem will araise at some scale with long-lived connections and infrastructure balancer/reverse proxy chain. So it's still required to tune.