First up, I hope you’re not using
NSURLConnection
. That API has been deprecated for many years now. The modern alternative is
NSURLSession
.
Having said that, both APIs share a common implementation of HTTP[S], so the fact that you’re using the legacy API is unlikely to be the cause of this problem.
You wrote:
There is no danger with these sites since they have been verified as operational and having valid content.
This is a common misconception. Even if there’s nothing obviously secret in play, there are still good reasons to run your requests over HTTPS:
It protects the user’s privacy. [I’m not a wine expert, so feel free to replace the following with a better wine ‘snob’ joke (-: ] Imagine if the user spends their time browsing winery sites for the cheapest wine with the highest alcohol content. It’s unlikely they want the whole world to know that, but that’s the risk you expose them too when you run your requests over HTTP.
It helps to protect your app from attack. When using HTTP you can’t trust the results you get back from the server at all. For example, the user might be running your app on a network that returns a maliciously crafted payload that exploits a security vulnerability in your app. That’s much harder to do if all your requests run over HTTPS.
I realise that you, as the app developer, can’t always fix this, and that sometimes you just have to talk to a server over HTTP. However, it’s never the case that this presents “no danger”.
You wrote:
both fail even after adding
NSAllowsArbitraryLoads
.
Hmmm.
NSAllowsArbitraryLoads
effectively turns off App Transport Security (ATS), so either you failed to set it properly or the problem isn’t with ATS.
It’s hard to say what’s going on without more details. Can you post an example URL that exhibits the problem?
Note This will require moderator approval but, don’t worry, I can take care of that.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
