masto.js 6.10.2 broke streaming API
With my GtS account, feeds are getting updates on elk.zone, but not on canary versions.
I looked through the commits between masto 6.10.1 (used in stable release) and 6.10.4 (currently in Elk's package.json) and found the cause: commit https://github.com/neet/masto.js/commit/7f01cb3f9c2c9f53f7bdbb9ad1d95fc4b4e9bab5, PR https://github.com/neet/masto.js/pull/1255
The client no more sends an access token via Sec-WebSocket-Protocol header, but neither sends Authorization header for some reason.
DevTools screenshot 1: errors in console
DevTools screenshot 2: 401 in response
Works on stable release, 101 in response
I can't track down the cause of clearing Authorization header. Masto.js builds the parameters for websocket connection correctly
WebSocketConnectorImpl calls new WebSocket(...this.props.constructorParameters)
It spreads an array constructorParameters that looks like:
[URL, [], {headers: {Authorization: ...}}] (open screenshot for details)
So WebSocket constructor gets URL, then [], and then an object.
Wait, I can't find the third parameter on MDN page about WS API. This StackOverflow answer also says that we cannot pass any headers to websocket constructor.
Maybe masto.js is supposed to be used with some custom websocket implementation (what?? definitely not in browser), but what I have is a native browser's WS that doesn't support headers.
It's a native impl
If the client library doesn't send an access token, i guess WS doesn't work on any server, not only GtS :)
https://github.com/neet/masto.js/commit/932463c03c985edb3a817992f38a42c3f10cc076 already reverted this change (included in release v7.1.0).
The latest version of masto.js uses Sec-WebSocket-Protocol again and should work.
@DarkCat09 Thanks for the detailed investigation! Yes, we should upgrade masto.js to the latest version.
glad i found this before I went too crazy- looking forward to the merge :)