Description
There is a long standing crash when using URLSession #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.