There is a long standing crash when using URLSession https://github.com/apple/swift-corelibs-foundation/issues/4791 that could more easily be worked around if URLSessionConfiguration initializers used URLProtocol.getProtocols() to populate the list of protocols to check on this object instead of a static list of [_HTTPURLProtocol.self, _FTPURLProtocol.self, _WebSocketURLProtocol.self].
Querying the URLProtocol system for the registered set of protocols would provide a safe route for Swift developers on non-Darwin systems to reimplement URL loading (if they choose to) for all 3rd party dependencies that they might pull in. Using the existing URLProtocol system would be less invasive than forking every dependency and patching in a different networking stack while maintaining cross platform compatibility.
Currently the docs about URLSessionConfiguration (https://developer.apple.com/documentation/foundation/urlsessionconfiguration) doesn't make mention about how the URLProtocol registration system factors into what gets used when you create a new instance of URLSessionConfiguration. The only relevant comments I can see are regarding the protocolClasses property which indicate extra protocols to use, but not how registered protocols factor into this API.
There is additional confusion that the built in protocols don't seem to show up in the protocolClasses array when using URLSessionConfiguration.default but are clearly still used since network requests can be made.
This patch set could be consistency in usage with what URLProtocols are available and used in all situations for URLSession.
There is a long standing crash when using URLSession https://github.com/apple/swift-corelibs-foundation/issues/4791 that could more easily be worked around if
URLSessionConfigurationinitializers usedURLProtocol.getProtocols()to populate the list of protocols to check on this object instead of a static list of[_HTTPURLProtocol.self, _FTPURLProtocol.self, _WebSocketURLProtocol.self].Querying the URLProtocol system for the registered set of protocols would provide a safe route for Swift developers on non-Darwin systems to reimplement URL loading (if they choose to) for all 3rd party dependencies that they might pull in. Using the existing URLProtocol system would be less invasive than forking every dependency and patching in a different networking stack while maintaining cross platform compatibility.
Currently the docs about
URLSessionConfiguration(https://developer.apple.com/documentation/foundation/urlsessionconfiguration) doesn't make mention about how the URLProtocol registration system factors into what gets used when you create a new instance ofURLSessionConfiguration. The only relevant comments I can see are regarding theprotocolClassesproperty which indicate extra protocols to use, but not how registered protocols factor into this API.There is additional confusion that the built in protocols don't seem to show up in the
protocolClassesarray when usingURLSessionConfiguration.defaultbut are clearly still used since network requests can be made.This patch set could be consistency in usage with what URLProtocols are available and used in all situations for URLSession.