[deaf_coder]

The part where it says:

> SSE works seamlessly with existing HTTP infrastructure:

I'd be careful with that assumption. I have tried using SSE through some 3rd party load balancer at my work and it doesn't work that well. Because SSE is long-lived and doesn't normally close immediately, this load balancer will keep collecting and collecting bytes from the server and not forward it until server closes the connection, effectively making SSEs useless. I had to use WebSockets instead to get around this limitation with the load balancer.

[jpc0]

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.

[sudhirj]

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.

[motorest]

> 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

[FZambia]

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.

[Igor_Wiwi]

thanks, updated the article with your comment