Repository navigation
Safari (macOS 12, iOS 15) and compression is broken #1347
Description
All versions of uWS are totally incompatible with iOS 15 when using compression and will not keep a connection. This is because of an Apple bug where client_no_context_takeover is not properly implemented in newest Safari for iOS 15.
Because of this, if you use compression and expect iOS 15 connections, you will have to enable uWS::DEDICATED_DECOMPRESSOR as well.
See EchoServer.cpp example. uWS::DEDICATED_DECOMPRESSOR is available in v20.3.0 and forward. This adds about 44kb of memory usage per connection.
Activity
[-]iOS 15 and compression is broken[/-][+]Safari (macOS 12, iOS 15) and compression is broken[/+]not-implemented commentedon Nov 9, 2021
Thanks for documenting this ... we ran into the same issue :-(
It really sucks ... as using
DEDICATED_DECOMPRESSORis not an option for us because of the massive RAM usage for ten thousands of connections ...Would be nice if you can keep us up2date if there are news on the apple issue.
not-implemented commentedon Jan 4, 2022
Still no news from Apple here, right? That's really annoying ;-)
ewak commentedon Jan 11, 2022
Here is what I think is the relevant issue in the webKit bugzilla
REGRESSION (iOS 15): Websocket connection instance in javascript client getting closed
https://bugs.webkit.org/show_bug.cgi?id=228296#c37
And a comment that gives ?hope? of an apple response.
Here is the link to the gist of the "go program" mentioned above - https://gist.github.com/afcapel/4e1012bd658f6818e70115178edd3489
And also relevant issues logged against the go gorilla/websocket implementation, further confirming that its a client issue.
gorilla/websocket#731
gorilla/websocket#696
The fix if there is one, to the "misplaced call to zlib's inflateReset", has not yet turned up in my installation of a beta release of IOS 15.3(19D5026g)
ewak commentedon Jan 13, 2022
This pull request #1399 contains an example, CompressionIOS15, if I have done it correctly, that shows that the use of the compression option DEDICATED_DECOMPRESSOR | DEDICATED_COMPRESSOR is not enough for a stable connection to an IOS 15.3(19D5026g) Iphone.
In my investigations I instrumented the calls to forceClose() in WebSocketProtocol.h:consumeMessage() as below.
CompressionIOS15, serves some simple html and javascript at test1.html that reproducibly results in the server aborting the connection, calling forceClose(), finding "wState->state.opStack == -1". I haven't figured out the meaning of opStack yet. That is hampering my progress bit level decoding of what is going on at the moment.
It is flaky. Sometimes giving up immediately, other times it may take various combinations of messages.
I watch the phones Safari console using a connected Desktop Safari Develop Web Inspector.
Big initial messages seem to trigger a forceClose more readily.
Sending multiple messages, "quickly", also seems to be a trigger.
I cannot trigger the issue with Deskop Safari Technology Preview Release 137 (Safari 15.4, WebKit 16613.1.11.8) on Big Sur.
ewak commentedon Jan 13, 2022
I will try to install some previous Safari Technology Previews to see if I can trigger it in an intermediate version.
Using
https://web.archive.org/web/*/https://secure-appldnld.apple.com/STP/*
Here is a link to a Nov 26, 2021
https://web.archive.org/web/20211126032655if_/https://secure-appldnld.apple.com/STP/001-62651-20201022-6cd92e18-bfbe-48cc-9385-d84da8f3c24c/SafariTechnologyPreview.dmg
Also now installing IOS 15.3 Public Beta 2 which was just released.
ewak commentedon Jan 13, 2022
The link above is to a old version Release 115 (Safari 14.1, WebKit 15611.1.3.5) compatible with 10.15, So useless for this purpose.
https://web.archive.org/web/20211126032655if_/https://secure-appldnld.apple.com/STP/001-62651-20201022-6cd92e18-bfbe-48cc-9385-d84da8f3c24c/SafariTechnologyPreview.dmg
10 remaining items
not-implemented commentedon Jan 29, 2022
Great! Thanks :-)
ewak commentedon Feb 2, 2022
Hi All,
Good news... maybe.
Looks to me using the IOS15Compression tests #1399 that the current release of IOS 15.4(19E5209h) public beta, installed on my IPhone, now has working compression.
Note: I have of course NOT incorporated the user agent hasBrokenCompression function above into my tests.
It works(tm) for me, for both shared and dedicated compression as shown below.
Shared compression
compressionFlavour = uWS::CompressOptions(uWS::SHARED_COMPRESSOR | uWS::SHARED_DECOMPRESSOR);Dedicated Compression
compressionFlavour = uWS::CompressOptions(uWS::DEDICATED_COMPRESSOR | uWS::DEDICATED_DECOMPRESSOR);not-implemented commentedon Feb 2, 2022
Oh ... sounds good! So we can hopefully change the version-check to target just "Safari 15.0-15.3"
not-implemented commentedon Feb 2, 2022
I created a pull request, that can be merged, when we are 100% sure, that Safari 15.4 is fixed:
#1414
This is the updated version of
hasBrokenCompression():Output:
Updated Safari hack to target 15.0-15.3 (#1347) (#1414)
ewak commentedon Mar 17, 2022
Hi Alex,
I saw your message re macos 12.3.
Its on my list to risk "destroying" one of my machines with yet another fresh os upgrade to macOS 12.3
I have not done so yet.
I can confirm that the official IOS 15.4 is working for my tests.
gaby23s commentedon Mar 17, 2022
Hi,
I still have the issue with an iPhone 8 and iOS 15.4 !
When I return after safari has been in the background for a while, the websocket is closed.
not-implemented commentedon Mar 17, 2022
@gaby23s are you sure, you are testing this very specific issue with Safari compression? This issue has nothing to do with putting Safari into the background ... in this scenario, Safari disconnects immediately after connect.
gaby23s commentedon Mar 18, 2022
Perhaps is not exactly the same issue.
But it seem linked: https://bugs.webkit.org/show_bug.cgi?id=228296
ewak commentedon Mar 18, 2022
@gaby23s We have also experienced MANY problems dealing with network re-connection after application sleep.
We fight it with a patched version of https://github.com/pladaria/reconnecting-websocket v4.2.0. (Here is our patched version - https://github.com/ewak/reconnecting-websocket/tree/feature/ewak/improvements) which I need to PR.
We use react, setup the websocket to start closed and attach an onerror() function. In the App componentDidMount() we reattach the onmessage(), onopen(), onclose() first and THEN call reconnect(). With IOS 15.4 this has again been working fine for us.
We also use React Native WebView(effectively safari) and have had many attempts to try to use native network information to know when it is worth attempting to reconnect, none of that got us anywhere reliably, and I suspect that privacy/anit-tracking improvements in IOS further limit the effectiveness of that.
Full disclosure - Be sure that you are really reconnecting to the correct place!!!
We had a long time nasty race condition due the accidental use of default connection parameters. We were failing to "await" the download and use runtime of configuration of the websocket connection details. Depending on the users phone, state of their browser cache, network latency the reconnection would race between the default configuration connecting to development servers(firewalled) rather than the runtime downloaded configuration environment(test, qa, prod).