Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Sent Events (SSE) Are Underrated

igorstechnoclub.com

Post reply on HN
Print view View original

101–110 of 153 posts

Re: Server-Sent Events (SSE) Are Underrated

#101

Post by leni536 »

atombender wrote: post #40
dugmartin wrote: post #8

It doesn’t mention the big drawback of SSE as spelled out in the MDN docs: “Warning: 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).”

One of my company's APIs uses SSE, and it's been a big support headache for us, because many people are being corporate firewalls that don't do HTTP/2 or HTTP/3, and people often open many tabs at the same time. It's unfortunately not possible to detect client-side whether the limit has been reached. Another drawback of SSE is lack of authorization header support. There are a few polyfills (like this one [1]) that si…

Supposedly websockets (the protocol) support authorization headers, but often there are no APIs for that in websocket libraries, so people just abuse the subprotocols header in the handshake.

Re: Server-Sent Events (SSE) Are Underrated

#102

Post by lakomen »

No they're not. They're limited to 6 clients per browser per domain on http/1.1 Which is important because nginx can't reverse proxy http/2 or higher, so you end up with very weird functionality, essentially you can't use nginx with SSE.

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

Edit: I see someone already posted about that

Re: Server-Sent Events (SSE) Are Underrated

#103

Post by leni536 »

apitman wrote: post #25
the_mitsuhiko wrote: post #20

Earlier quoted context omitted.

That might very well be but the future is not today.

But why add it to HTTP/3 at all? HTTP/1.1 hijacking is a pretty simple process. I suspect HTTP/3 would be significantly more complicated. I'm not sure that effort is worth it when WebTransport will make it obselete.

To have multiple independent websocket streams, without ordering requirements between streams.

Re: Server-Sent Events (SSE) Are Underrated

#105

Post by upghost »

jauco wrote: post #93
upghost wrote: post #48

Earlier quoted context omitted.

There's no ack on a raw SSE stream, unfortunately -- unless you mean send an event and expect the client to issue an HTTP request to the server like a keepalive?

There should be an ACK on the tcp packet (IIRC it’s not a lateral ACK but something like it) and the server should handle a timeout on that as the connection being “closed” which can be returned to the connection opener. You might want to look into timeouts or error callbacks on your connection library/framework.

Interesting, hadn't checked at the TCP level. Will need to look into that.

Re: Server-Sent Events (SSE) Are Underrated

#106

Post by tomsmeding »

raggi wrote: post #50
jesprenj wrote: post #37

Earlier quoted context omitted.

You can easily multiplex data over one connection/event stream. You can design your app so that it only uses one eventstream for all events it needs to receive.

This, it works well in a service worker for example.

The caniuse link in the OP, under Known Issues, notes that Firefox currently does not support EventSource in a service worker. https://caniuse.com/?search=EventSource

Re: Server-Sent Events (SSE) Are Underrated

#107

Post by tomsmeding »

nhumrich wrote: post #82
apitman wrote: post #10

> Perceived Limitations: The unidirectional nature might seem restrictive, though it's often sufficient for many use cases For my use cases the main limitations of SSE are: 1. Text-only, so if you want to do binary you need to do something like base64 2. Browser connection limits for HTTP/1.1, ie you can only have ~6 connections per domain[0] Connection limits aren't a problem as long as you use HTTP/2+. Even so, I d…

ReadableStream appears to be SSE without any defined standards for chunk separation. In practice, how is it any different from using SSE? It appears to use the same concept.

Presumably, ReadableStream does not auto-reconnect.

Re: Server-Sent Events (SSE) Are Underrated

#108

Post by jauco »

upghost wrote: post #105
jauco wrote: post #93

Earlier quoted context omitted.

There should be an ACK on the tcp packet (IIRC it’s not a lateral ACK but something like it) and the server should handle a timeout on that as the connection being “closed” which can be returned to the connection opener. You might want to look into timeouts or error callbacks on your connection library/framework.

Interesting, hadn't checked at the TCP level. Will need to look into that.

I remembered wrong. In most circumstances a tcp connection will be gracefully terminated by sending a FIN message. The timeout I talked about is on an ACK for a keepalive message. So after x time of not receiving a keepalive message the connection is closed. This handles cases where a connection is ungracefully dropped.

All this is done at the kernel level, so at the application level you should be able to just verify if the connection is open by trying a read from the socket.

Re: Server-Sent Events (SSE) Are Underrated

#109

Post by aniketchopade »

I had some trouble implementing when server has to wait for another endpoint (webhook) to feed output to browser . During request processing (thread1) had to store the sse context in native Java object which will be retrieved later when webhook(thread2) is called But then with multiple service instance you wouldn't know which service had stored it so webhook had to publish something which others has to subscribe.

Re: Server-Sent Events (SSE) Are Underrated

#110

Post by lolinder »

nhumrich wrote: post #80
dugmartin wrote: post #8

It doesn’t mention the big drawback of SSE as spelled out in the MDN docs: “Warning: 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).”

Http2 is controllable by you, since it's supposed in every browser. So, the way to fix this limitation is to use http2

This was already suggested and someone pointed out that some corporate networks MITM everything without HTTP/2 support:

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

Post reply on HN