[URLSession] Do not crash for unsupported URLs

[karwa]

Tasks which request unsupported URL protocols, or which request nil URLs, should return "unsupported URL" errors rather than crash. Matches Darwin behaviour.

[karwa]

Simple test to run on Darwin (e.g. from the REPL):

import Foundation 
URLSession.shared.dataTask(with: URL(string: "foo://x")!) { print("RESPONSE: \($0) \($1) \($2)") }.resume() 
sleep(2)

Outputs:

2022-03-15 18:49:09.790247+0100 repl_swift[7976:787486] Task <F43E800A-93A6-4132-8E7C-2FDCCBA6180B>.<8> finished with error [-1002] Error Domain=NSURLErrorDomain Code=-1002 "unsupported URL" UserInfo={NSLocalizedDescription=unsupported URL, NSErrorFailingURLStringKey=foo://x, NSErrorFailingURLKey=foo://x, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <F43E800A-93A6-4132-8E7C-2FDCCBA6180B>.<8>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <F43E800A-93A6-4132-8E7C-2FDCCBA6180B>.<8>, NSUnderlyingError=0x10040d4f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1002 "(null)"}}
RESPONSE: nil nil Optional(Error Domain=NSURLErrorDomain Code=-1002 "unsupported URL" UserInfo={NSLocalizedDescription=unsupported URL, NSErrorFailingURLStringKey=foo://x, NSErrorFailingURLKey=foo://x, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <F43E800A-93A6-4132-8E7C-2FDCCBA6180B>.<8>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <F43E800A-93A6-4132-8E7C-2FDCCBA6180B>.<8>, NSUnderlyingError=0x10040d4f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1002 "(null)"}})

[tomerd]

thanks @karwa once merged, should this also be back ported to 5.6?

[karwa]

I'd be happy to back-port it to 5.6. I actually need this behaviour for something that I'd like to ship.

(It's for WebURL foundation extensions - i.e. making URLSession requests directly using a WebURL value. It works on Darwin because a WebURL -> NSURL conversion failure can just make a request to a nil URL and propagate an error via the usual channels, but on Linux the same procedure crashes)

[karwa]

Ping @millenomi

I haven't actually been able to run TestFoundation on my Mac, since after following the instructions in the README, I get a bunch of errors about duplicate/ambiguous symbols from CoreFoundation (some conflict between the SDK module map and the included one), and running the tests on Linux involves building the entire Swift project.

That said, I manually verified this on my Mac by adding a small executable target to the Foundation workspace which imported SwiftFoundationNetworking rather than Foundation. I verified that it hit the crash before the fix (so wasn't using the SDK copy) and didn't hit the crash after the fix.

So I'd appreciate somebody triggering CI tests and letting me know if there are updated instructions to run TestFoundation on the Mac (or an easier way to run them on Linux).

[karwa]

@millenomi Are you able to review this patch, or recommend somebody?

[millenomi]

@swift-ci please test and merge

[millenomi]

Yeah, please stand by wrt macOS.

[karwa]

@millenomi Would you be able to trigger tests again? Seems from the other PR that plain swift-ci "test" works.

[YOCKOW]

@swift-ci Please test

[tomerd]

@karwa this would be nice to get into 5.6.3: https://forums.swift.org/t/development-open-for-swift-5-6-3-for-linux-and-windows/58859

Can we get CI green so its mergable?

cc @parkera @shahmishal

[tomerd]

@karwa this would be nice to get into 5.7

Can we get CI green so its mergable and brought over the the 5.7 branch?

cc @parkera @shahmishal

[karwa]

@tomerd Apologies for the lateness; I think it should be fixed now. Could you trigger CI again, please?

[tomerd]

@swift-ci Please test

[tomerd]

@parkera you okay to merge this?

[parkera]

Thank you!

[tomerd]

@karwa @parkera do we want to try and pull this into 5.7 branch? cc @shahmishal