How is a proxy connection made with URLSession?

Question

I've been looking at Apple's WWWDC 2015 Session 711: "Networking with NSURLSession". Towards the end, the speaker mentions URLSessionStreamTask, which can be used for direct socket I/O. And he mentions how a (HTTP) proxy connection can be transitioned to a stream-task.

A slide contains:

NSURLSessionStreamTask
DataTask conversion

NSURLSessionDataTask may be converted to a stream task
• Use NSURLSession to get through HTTP proxies
Conversion can occur when response is received

And the next slide has partial sample code:

func URLSession(session: NSURLSession, dataTask: NSURLSessionDataTask,
                    didReceiveResponse response: NSURLResponse,
                              completionHandler: (NSURLSessionResponseDisposition) -> Void) {
    completionHandler(.BecomeStream)
}

func URLSession(session: NSURLSession, dataTask: NSURLSessionDataTask,
                 didBecomeStreamTask streamTask: NSURLSessionStreamTask) {
}

I want to know how to create the proxy connection in the first place. And using the data from the "System Preferences" : Network : Advanced : Proxies panel if possible. (Not just the "HTTP" proxy, but any of the other 4 with the same format.)

And since they usually use HTTP instead of HTTPS, do such connections trigger ATS (App Transport Security)?

Answer 1

What they're talking about is support for the WebSocket protocol, which allows you to open a connection to a web server, then upgrade that connection to a web socket, thus allowing you to communicate directly with whatever script or CGI program is on the other end without having to conform to the traditional request-response style.

What I think they were trying to say was that if you are sending HTTP (ick) requests via a proxy that actually supports WebSocket communications, iOS knows how to ask the proxies to upgrade the connection properly. This same upgrade mechanism is often used for making an HTTPS request through an HTTP proxy, where supported, and if you make an HTTPS connection, the subsequent WebSockets upgrade should work in spite of the proxy no matter what, because the proxy is already just passing bits back and forth by that point.