I'm curious as to how everyone deals with HTTP/2 requirements between the backend servers and the load balancer? By default, HTTP/2 requires TLS which means either no SSL termination at the load balancer or a SSL cert generated per server with a different one for the front end load balancer. This all seems very inefficient.
Server-Sent Events (SSE) Are Underrated
81–90 of 153 posts
Re: Server-Sent Events (SSE) Are Underrated
#82> 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…
Re: Server-Sent Events (SSE) Are Underrated
#83Does anyone have a good trick for figuring out when the client side connection is closed? I just kill the connection on the server every N minutes and force the client to reconnect, but it's not exactly graceful. Secondly, on iOS mobile, I've noticed that the EventSource seems to fall asleep at some point and not wake up when you switch back to the PWA. Does anyone know what's up with that?
Re: Server-Sent Events (SSE) Are Underrated
#84I'm curious as to how everyone deals with HTTP/2 requirements between the backend servers and the load balancer? By default, HTTP/2 requires TLS which means either no SSL termination at the load balancer or a SSL cert generated per server with a different one for the front end load balancer. This all seems very inefficient.
You don't need http2 on the actual backend. All limitations for SSE/http1 are browser level. Just downgrade to http1 from the LB to backend, even without SSL. As long as LB to browser is http2 you should be fine.
Re: Server-Sent Events (SSE) Are Underrated
#85Earlier quoted context omitted.
But then why not just use websockets?
From what I understand websockets are great until you have to load balance them. And then you learn why they aren’t so great.
You need to scale up before your servers become overloaded, and basically new connections go north to the newly brought up server. It is a different mentality than scaling stateless services but it isn't super duper hard.
Re: Server-Sent Events (SSE) Are Underrated
#86For FastAPI if you want some hooks when client disconnects aka nginx 499 errors, follow this simple tip
https://github.com/encode/starlette/discussions/1776#discuss...
Re: Server-Sent Events (SSE) Are Underrated
#87Earlier 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.
My point is mostly that SSE works well and is supported and that has A meaningful benefit today.
Re: Server-Sent Events (SSE) Are Underrated
#88Earlier quoted context omitted.
That is a very low number. I can think of many reasons why one would end up with more. Does anyone know why it is so low?
Historical reasons. The HTTP/1.1 spec actually recommends limited to 2 connections per domain. That said, I'm not sure why it's still so low. I would guess mostly to avoid unintended side effects of changing it.
This is no longer true.
From RFC 9112 § 9.4 (https://httpwg.org/specs/rfc9112.html#rfc.section.9.4):
> Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.
Re: Server-Sent Events (SSE) Are Underrated
#89Earlier quoted context omitted.
That is a very low number. I can think of many reasons why one would end up with more. Does anyone know why it is so low?
Historical reasons. The HTTP/1.1 spec actually recommends limited to 2 connections per domain. That said, I'm not sure why it's still so low. I would guess mostly to avoid unintended side effects of changing it.
When index.html loads 4 CSS and 5 JS : 10 ressources in HTTP 1.0 needed 10 connections, with 10 TLS negociations (unless one ressource loaded fast and you could reuse it's released connection)
With HTTP1.1 Pipelining you open only one connection, including a single TLS nego, and ask 10 ressources.
Why not only 1 per domain so ? IIRC it's because the 1st ressource index.html may take a lot of Time to complete and well race conditions suggest you use another one that the 'main thread' more or less. So basically 2 are sufficient.
Re: Server-Sent Events (SSE) Are Underrated
#90I have a hard time imagining the tech's limits outside of testing scenarios so some of the examples brought up here are interesting