What are the consequences of disabling the experimental feature NSURLSession WebSocket in Safari?

Question

I was told to disable the NSURLSession Websocket experimental feature to work around a claimed Safari bug. Doing so did solve my problem, but I want to make sure it doesn't have any unintended consequences. What are the implications of disabling that experimental feature? The setting can be found in Settings -> Safari -> Advanced -> Experimental Features -> NSURLSession WebSocket. It's enabled by default.

My specific case involves the gamja web IRC client as used on https://chat.sr.ht. I can use it fine in other browsers, such as Firefox on macOS, but when I log in to the client in Safari on iOS I get constant disconnects and reconnects. I asked for help from sr.ht, and was told that the problem was a Safari bug and to disable this feature. However, when I asked if there were other consequences for doing this, no one seemed to know.

I see a lot of advice online to turn off this feature to solve various problems with everything from IP cameras to Coinbase Pro to Slack. Some sources claim the issue is fixed by recent software updates, but I'm on the latest iOS and disabling the feature did solve my problem, so I'm not sure if my problem is different or the issue isn't actually fixed.

What does this feature do when enabled, and will I break something else by turning it off?

iOS 17 update

This is no longer available as a toggle, and appears to be set to on all the time.

Answer 1

There are most probably no consequences at all to turning it off (besides fixing the issue you're running into).

The long story:

WebSocket is a network protocol employed by browsers to allow web page to have longlived, two-way communication with a compliant server. An example usage could be a chat application that allows sending and receiving chat messages over the WebSocket connection - without having to constantly open up new connections to check for new messages.

NSURLSession is an API (application programming interface) provided by Apple for developers to facilitate data transfers. Typically it is used for tasks such as downloading images and other data in apps. It supports several protocols such as HTTP, FTP and others. Apple has extended that with support for the WebSocket protocol in iOS 13 as far as I remember.

Recently, Apple has pushed developers a lot in the direction of using NSURLSession for all their data transfer needs - instead of having each app implement this themselves. This is probably due to the fact that NSURLSession handles a lot of functionality that is very useful to user's, but in many cases could be skipped over by third party developers. Things like handling downloads when the app is backgrounded, prioritising the downloads within an app and amongst app, ensuring proper in-transport security, lowering power usage, etc.

Many apps embed an web-browser inside their app. This is typically done via Apple's WKWebView API. Historically, the WKWebView API supported WebSocket via its own implementation.

The experimental setting in this question is simply about whether you want to use the old, built-in to WKWebView WebSocket implementation, or you want the newer built-in to NSURLSession WebSocket implementation.

Basically, you probably would want the new implementation - unless it happens to have some bug that Apple hasn't fixed yet, which is annoying you. This is why Apple has kept it as experimental and made it possible for you to configure the choice of implementation.

The bug in question seems to be that the new implementation has a different way of implementing (perhaps erraneously) fragmented data packets when compression is enabled. I.e. a very large piece of data is sent over WebSocket, it cannot be sent in a single data packet, and has to be split over multiple packets.