3 ms·
To this day I still dont know why WebSockets and SSE dont support sending headers on the initial request, such as Authorization. Leaving authentication on realt
by Fabricio20 3y ago
To this day I still dont know why WebSockets and SSE dont support sending headers on the initial request, such as Authorization. Leaving authentication on realtime services entirely up to whoever is implementing the service.
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.
- omgtehlion 3y agoWait, what?? Been using these for years. Am I missing something?
- apitman 3y agoThey're probably referring to browsers specifically. The WebSocket constructor doesn't allow for headers
- tytho 3y agoThe browser EventSource constructor does not have options to pass in your own headers. You can pass an option to have it use the cookies for the domain you’re using. There are libraries that allow you to pass in additional HTTP options, but they essentially reimplement the built-in EventSource object in order to do so. Not terribly difficult, fairly simple spec.
- omgtehlion 3y agoWell, that constructor by default sends all the headers you have for your own domain and auth you are entitled to. This is how all other APIs in browsers work due to security and privacy concerns. If you call to other domains, then this problem is no different to what we had with CORS years ago.
- apitman 3y ago> This is how all other APIs in browsers work due to security and privacy concerns They're probably comparing it to the fetch and XHR APIs, which both allow custom headers.
- michaelt 3y ago> To this day I still dont know why WebSockets and SSE dont support sending headers on the initial request Doesn't the initial request get to send a full set of standard HTTP headers, cookies and all?
- paulgb 3y agoIt does, but if you're calling it from the browser you can't add arbitrary data to them (the way you can in e.g. a `fetch`)
- dist-epoch 3y agoThey do send cookies.
- Sammi 3y agoI do login the bog standard way with a regular old http request and the server responds with setting an http only cookie. Then I reconnect the websocket, which will then provide the cookie to the server on reconnect.
- cbsmith 3y agoThere's always TLS certificates... ;-)
- paol 3y agoOooh boy you touched a pet peeve. I mean who needs authentication on the modern Web right? /s 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.
- rexxars 3y agoThe EventSource API (the browser "client API" for Server-Sent Events) leaves a lot to be desired. While I am a maintainer of the most used EventSource polyfill[1], I've recently started a new project that aims to be a modern take on what an EventSource client could be: https://github.com/rexxars/eventsource-client https://github.com/rexxars/eventsource-client. 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. [1]: https://github.com/eventsource/eventsource https://github.com/eventsource/eventsource
- martypitt 3y agoNice work! This addresses many of the issues I've had with SSE. 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.
- skinner927 3y agoJust read the spec Clients will reconnect if the connection is closed; a client can be told to stop reconnecting using the HTTP 204 No Content response code.