Did research on SSE a short while ago. Found out that the mimetype "text/event-stream" was blocked by a couple of anti-virus products. So that was a no-go for us.
Server-Sent Events: an alternative to WebSockets
31–40 of 266 posts
Re: Server-Sent Events: an alternative to WebSockets
#32Earlier quoted context omitted.
Aha, well why do you need to send a header when you can just put the data on the GET URL like so "blabla?cookie=erWR32" for example? In my example I use this code: var source = new EventSource('pull?name=one'); source.onmessage = function (event) { document.getElementById('events').innerHTML += event.data; };
What if you use http-only cookies?
You can pass a ‘withCredentials’ option.
Re: Server-Sent Events: an alternative to WebSockets
#33My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better.
Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.
Re: Server-Sent Events: an alternative to WebSockets
#34I made the backend for this MMO on SSE over HTTP/1.1: https://store.steampowered.com/app/486310/Meadow/ We have had a total of 350.000 players over 6 years and the backend out-scales all other multiplayer servers that exist and it's open source: https://github.com/tinspin/fuse You don't need HTTP/2 to make SSE work well. Actually the HTTP/2 TCP head-of-line issue and all the workarounds for that probably make it hard…
Can you explain how H2 would make it harder to scale SSE?
Re: Server-Sent Events: an alternative to WebSockets
#35Did research on SSE a short while ago. Found out that the mimetype "text/event-stream" was blocked by a couple of anti-virus products. So that was a no-go for us.
How did you find that out?
Re: Server-Sent Events: an alternative to WebSockets
#36I can’t find any downsides of SSE presented. My experience is that they’re nice in theory but the devils in the details. The biggest issue being that you basically need http/2 to make them practical.
Absolutely not, HTTP/1.1 is the way to make SSE fly: https://github.com/tinspin/rupy/wiki/Comet-Stream Old page, search for "event-stream"... Comet-stream is a collection of techniques of which SSE is one. My experience is that SSE goes through anti-viruses better!
> My experience is that SSE goes through anti-viruses better!
Hmm, another commenter says the opposite:
Re: Server-Sent Events: an alternative to WebSockets
#37So do I understand correctly that when using SSE, the login cookie of the user is not automatically sent with the SSE request like it is with all normal HTTP requests? And I have to redo auth somehow?
It should automatically send first party cookies, though you may need to specify withCredentials.
Re: Server-Sent Events: an alternative to WebSockets
#38My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.
What? How do they not support headers?
You have to send "Content-Type: text/event-stream" just to make them work.
And you keep the connection alive by sending "Connection: keep-alive" as well.
I've never had any issues using SSEs.
Re: Server-Sent Events: an alternative to WebSockets
#39One issue with SSE is that dumb enterprise middleboxes and Windows antivirus software break them :( They'll try to read the entire stream to completion and will hang forever.
I managed to get through almost all middle men by using 2 tricks: 1) Push a large amount of data on the pull (the comet-stream SSE never ending request) response to trigger the middle thing to flush the data. 2) Using SSE instead of just Comet-Stream since they will see the header and realize this is going to be real-time data. We had 99.6% succes rate on the connection from 350.000 players from all over the world (e…
While 350k simultaneous connections is nice, I'd be extremely skeptical of that being any kind of world record
Re: Server-Sent Events: an alternative to WebSockets
#40SSEs had a severe connection limit, something like 4 connections per domain per browser (IIRC), so if you had four tabs open then opening new ones would fail.