NSURLSession Websockets in Safari on Mac OS Monterrey beta does not connect
Closed this issue · 1 comments
It looks like Safari switched their default websocket client to NSURLSession Websockets in Monterrey. That implementation of a websocket client contains a bug.
The bug is that NSURLSession Websockets requests compression by including the Sec-WebSocket-Extensions: permessage-deflate header, but ignores when the server responds as not supporting it, and continues assuming the connection is compressed. Here is a repro and nice write-up.
It looks like push stream does not support compression (at least as of 2017). This means that as people upgrade and start using Monterrey's version of Safari, websockets backed by this module will not connect.
What is unclear is even if push stream supported compression if that would fix the issue. Here is a comment stating that it may not work:
(from the link)
TL;DR: if a websocket server doesn't support compression, the client enables it nonetheless which is a protocol violation. If the server does accept compression, the client still ends up in an invalid state on messages sent to the server after the first one (slightly different behavior if context takeover is enabled vs. not).
However, at my work we have an alternative websocket server that is working with Monterrey's Safari with both pings, pongs, and receiving multiple messages so it seems to be an issue with push stream's implementation specifically mixed with the bug in Safari.
As a workaround NSURLSession Websockets is able to be disabled within Safari, but this solution is not tenable for our production traffic.
We will also be submitting a bug report to Apple and I'll update with the link to that when it is submitted.
The intention of this issue is a friendly heads up since people will be upgrading to Monterrey.
I wanted to follow up on this and say it appears that Apple has fixed this issue in Safari on Monterrey using their NSURLSession Websockets.