Possibly in relation with https://bugs.webkit.org/show_bug.cgi?id=170463 but posting a new bug.
Safari 13 both on macOS Catalina and iOS 13.2 fails to send large websocket frames.
In our testing, sending frames under 1k to a Twilio-specific connection works fine, but after sending a few large frames (about 32k each) the connection fails with
WebSocket connection to 'wss://tsock.us1.twilio.com/v3/wsconnect' failed: Failed to compress frame
WebSocket connection to 'wss://tsock.us1.twilio.com/v3/wsconnect' failed: Failed to send WebSocket frame.
This is a REGRESSION because the same sequence works well in Safari 12 with all the other configuration remaining the same.
I don't have a minimal example in itself, since we're using Twilio Chat quickstart to test. Just sending frames through websocket in one direction does not seem to trigger that error.
However there's a copy of the quickstart repository that contains all necessary information to start testing.
1. Grab the repository from here: https://github.com/berkus/twilio-chat-quickstart-safari13-repro/tree/safari13-repro
2. In public/chat/index.js find the text INSERT_URL_HERE and replace it with the token generator url which has already been preconfigured for you: https://aquamarine-cichlid-8646.twil.io/token?key=_aapl_repro98767542432
3. Run `npm install` and start the server using `node run start`
4. Navigate Safari to localhost:3000/chat
5. It will try to fetch and paginate approximately 600 channels and at some point you will see a NOT_ACCEPTABLE_MESSAGE response from our websocket server. At the same point there will be "Failed to compress frame" message in the console log.
Please note that NOT_ACCEPTABLE_MESSAGE is the response of our server due to break of protocol between server and client (client attempts a reconnection) - and that happens because of the failure of Safari to compress and send a frame. This is a REGRESSION in Safari 13 and it works properly in Safari 12.
We will be happy to assist with debugging this issue further.
Could be same as bug 202401, but needs further analysis to confirm.
Looks very similar indeed, I will check if the "x-webkit-deflate-frame extension" is enabled for us.
Can it be force-disabled from the server-side somehow?
We have force-disabled support for "x-webkit-deflate-frame" extension on the server side. This seems to work around the problem for the time being.
I hope to see actual working permessage-deflate support in WebKit at some point in time.
Based on this, marking as a duplicate of bug 202401.
*** This bug has been marked as a duplicate of bug 202401 ***