4 ms·

How well do these work out in practice across a variety of platforms, behind firewalls, on phones, and so on?

by davidw 3y ago

lecarore 3y ago
I use this at work (Enterprise SAAS web software) and we had to implement a backup "polling every 5 seconds" for clients that would not support it. It's quite rare though. We assume that some caching proxy might be waiting for the GET request to be fully done to cache it and then give it to the user or something like this. The SSE would then never get updates, while every normal HTTP request would work
- jlokier 3y ago
  I've read that this does indeed happen with some HTTP proxies. In some environments that includes HTTPS because some environments intercept HTTPS traffic too. It's enough for me to consider SSE too unreliable to use if my application needs to be reliable with events, and it's the first thing I thought when I saw the SSE spec the first time. Back beore SSE, I recall seeing some server-to-client event protocol specification inserted extra padding bytes after events in the middle of an HTTP response stream, just to convince some HTTP proxies to forward the event in an incomplete HTTP response, but I don't recall which protocol now. It was never entirely clear how much padding would be enough, or if any amount would be. When cometd and the Bayeux publish-subscribe protocol was designed, this is why long-polling was always used, instead of streaming partial responses inside a single HTTP response. With correctly designed overlapping long-polling requests, it's possible to get event latency very similar to SSE, without this issue of lost events due to proxies. So that's a good, reliable choice, if you don't use WebSockets. In fact it's more reliable than WebSockets (which can also get stuck at some proxies), so if you value very reliable event delivery long-polling or just periodic polling are the way to do it, but with much higher overhead. In theory SSE provides the option for mobile device power saving described at https://html.spec.whatwg.org/multipage/server-sent-events.html#eventsource-push https://html.spec.whatwg.org/multipage/server-sent-events.ht... Using more active protocols almost certainly defeats this. In theory a mobile network and network stack (modified inside the mobile browser where cleartext is available) could implement that power saving strategy for mostly-idle WebSockets too, which is another argument for WebSockets.
Mogzol 3y ago
They're well supported on modern browsers, both mobile and desktop. If you need to support IE then you can use a polyfill. It's essentially just a long-running HTTP request. The main issue I've run into before is if your server has a response timeout configured then you'll need to disable or work around it, otherwise it will disrupt the event stream whenever the timeout is hit, since the event stream is just an HTTP response.
deleted 3y ago
[deleted]
bullen 3y ago
They work EVERYWHERE except through some very rare buggy anti-viruses and ISP implementations. Real life stats: "759 out of 205.875 customers refunded because their antivirus blocks the pull HTTP stream", so 99.7%! They even go through the great firewall without bureaucracy.

How well do these work out in practice across a variety of platforms, behind firewalls, on phones, and so on?

by davidw 3y ago

How well do these work out in practice across a variety of platforms, behind firewalls, on phones, and so on?

I use this at work (Enterprise SAAS web software) and we had to implement a backup "polling every 5 seconds" for clients that would not support it. It's quite rare though. We assume that some caching proxy might be waiting for the GET request to be fully done to cache it and then give it to the user or something like this. The SSE would then never get updates, while every normal HTTP request would work

jlokier 3y ago
I've read that this does indeed happen with some HTTP proxies. In some environments that includes HTTPS because some environments intercept HTTPS traffic too. It's enough for me to consider SSE too unreliable to use if my application needs to be reliable with events, and it's the first thing I thought when I saw the SSE spec the first time. Back beore SSE, I recall seeing some server-to-client event protocol specification inserted extra padding bytes after events in the middle of an HTTP response stream, just to convince some HTTP proxies to forward the event in an incomplete HTTP response, but I don't recall which protocol now. It was never entirely clear how much padding would be enough, or if any amount would be. When cometd and the Bayeux publish-subscribe protocol was designed, this is why long-polling was always used, instead of streaming partial responses inside a single HTTP response. With correctly designed overlapping long-polling requests, it's possible to get event latency very similar to SSE, without this issue of lost events due to proxies. So that's a good, reliable choice, if you don't use WebSockets. In fact it's more reliable than WebSockets (which can also get stuck at some proxies), so if you value very reliable event delivery long-polling or just periodic polling are the way to do it, but with much higher overhead. In theory SSE provides the option for mobile device power saving described at https://html.spec.whatwg.org/multipage/server-sent-events.html#eventsource-push https://html.spec.whatwg.org/multipage/server-sent-events.ht... Using more active protocols almost certainly defeats this. In theory a mobile network and network stack (modified inside the mobile browser where cleartext is available) could implement that power saving strategy for mostly-idle WebSockets too, which is another argument for WebSockets.

Mogzol 3y ago

They're well supported on modern browsers, both mobile and desktop. If you need to support IE then you can use a polyfill. It's essentially just a long-running HTTP request. The main issue I've run into before is if your server has a response timeout configured then you'll need to disable or work around it, otherwise it will disrupt the event stream whenever the timeout is hit, since the event stream is just an HTTP response.

deleted 3y ago

[deleted]

bullen 3y ago

They work EVERYWHERE except through some very rare buggy anti-viruses and ISP implementations. Real life stats: "759 out of 205.875 customers refunded because their antivirus blocks the pull HTTP stream", so 99.7%! They even go through the great firewall without bureaucracy.