I may be wrong here and the spec suggests a good way to do it, but i've seen so many different approaches that at this point might as well say there's none.
Beyond handling the custom headers aspect, it also supports any request method (POST, PATCH..), allows you to include a request body, allows subscribing to any named event (the EventSource `onmessage` vs `on('named event')` is very confusing), as well as setting an initial last event ID (which can be helpful when restoring state after a reload or similar). And you can use it as an async iterator.
I love the simplicity of Server-Sent Events, but the `EventSource` API seem to me like a rushed implementation that just kinda stuck around.
Another problem we've never worked out the solution to, is how to send a termination - signalling "there are no more events coming". We always end up having to roll our own, though it felt like something that should've been handled at the protocol layer.
Clients will reconnect if the connection is closed; a client can be told to stop reconnecting using the HTTP 204 No Content response code.
Doesn't the initial request get to send a full set of standard HTTP headers, cookies and all?
What about intercepting the request with a service worker?
If you call to other domains, then this problem is no different to what we had with CORS years ago.
They're probably comparing it to the fetch and XHR APIs, which both allow custom headers.
The even more irritating thing is that there is nothing preventing this, and every server I've tried supports it. It's only the browser WebSocket API that was designed without this. Cookies are the only thing browsers will deign to send in the initial request.