cordova-plugin-ionic-webview: iOS v12 Https requests errors / Https requests don't reach backend

Bug Report

Describe the Bug

We, I and other Ionites, noticed that https requests on iOS v12 are failing respectively never reach our backends. Some are facing preflight error or typical CORS errors but in any case, requests aren’t reaching our backend.

When it comes to me, I could confirm that my app is productive and the fact that this error only occurs on iOS >= v12

Errors

In Xcode 10 Beta I get the following error:

{“headers”:{“normalizedNames”:{},“lazyUpdate”:null,“headers”:{}},“status”:0,“statusText”:“Unknown Error”,“url”:null,“ok”:false,“name”:“HttpErrorResponse”,“message”:“Http failure response for (unknown url): 0 Unknown Error”,“error”:{“isTrusted”:true}}

I added so much log I could on my backend API side, unfortunately nothing was parsed, it looks like nothin reach it

Report

I have reported my problem to Apple too. Can’t tell if it’s an iOS v12 bug or an improvement which should be developed in the WkWebView plugin in order to be compatible for v12, therefore I allowed my self to open this issue

Other resources

Discussion on the Ionic forum: https://forum.ionicframework.com/t/ios-12-beta-preflight-requests-fail/132177/9

Open radar about a similaire issue: https://openradar.appspot.com/radar?id=4959044250894336

Stackoverflow: https://stackoverflow.com/questions/50707146/ios-v12-https-requests-errors

Version

cordova-plugin-ionic-webview: 1.2.1 ionic-angular: 3.9.2 angular/http: 5.0.0 node: 10.2.1

Note

It fails with any https requests but if you need a repo to reproduce the problem, sure let me know, I will take the time if needed

Node / Express

I set the following headers in my backend, which like I said, works find till iOS < v12

var allowedOrigins = ["https://example.com", "http://ionic.local", "http://localhost:8080"];

 var origin = req.headers.origin;
 if(allowedOrigins.indexOf(origin) > -1){
        res.setHeader('Access-Control-Allow-Origin', origin);
 } else {
        res.setHeader("Access-Control-Allow-Origin", "https://example.com");
    }

 res.header("Access-Control-Allow-Credentials", "true") 
 res.header("Access-Control-Allow-Headers", "Origin, Authorization, Content-Type, Content-Range, Content-Disposition, Content-Description, X-Requested-With, X-ACCESS_TOKEN");
 res.header("Access-Control-Allow-Methods", "GET,PUT,POST");

Note: Even if I set res.setHeader('Access-Control-Allow-Origin', '*'); if won’t work, really have the feeling the https query doesn’t reach the backend, I did add some logging in that section of my backend but nothing was logged

Side note

On the same simulated device with iOS v12, I opened Safari and used my Angular web app to see if I was facing the same problem (in my web app I use angular http too the query the same backend) which actually wasn’t the case, no problem there

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 18
Comments: 42 (8 by maintainers)

Most upvoted comments

Hello guys! Yeah, I have the same problem for iOS 12.4

+12

samalfaro92 on Dec 16, 2019

@peterpeterparker @mhartington issue fixed in iOS 12 beta 2. Get it from https://developer.apple.com/download/ 😃

maxkunitsa on Jun 19, 2018

Haven’t tried iOS 12 yet, but I can say that from iOS > 11.3 WKWebView fails on navigator.sendBeacon to HTTPS. The same POST with XHR is successful (also HTTP is successful, it’s a TLS issue).

The client seems to break the connection right after the TLS handshake is complete. and console shows “Failed HTTP authentication” error. Interestingly, forcing the browser to preconnect with: <link href='https://...' rel='preconnect' crossorigin/> before calling sendBeacon makes it succeed (seems that preconnect creates a valid TLS session that can then be reused).

Wild guess, but perhaps XHR in iOS 12 is now reusing the same code that broke sendBeacon in > 11.3?

lassic on Jun 12, 2018

Awesome, thanks for all the information/updates everyone.

For now, since we know this is a confirmed issue inside of iOS12/WKWebview proper, and not an error inside the plugin or any backends being used, let’s hold off until the next build of iOS 12 is released.

Thanks for all the information 💪

mhartington on Jun 13, 2018

@peterpeterparker Thanks for the issue! We’ll be tracking this and keeping an eye on things. WWDC builds of iOS tend to have quite a few bugs, so we’ll need to keep checking this, as it could be a bug in this build of WKWebview

mhartington on Jun 6, 2018

I test HTTP work well, but HTTPS run into this issue. when post with form-data work well, if post with son-data, will run into this issue

Serlight on Jun 12, 2018

For the record, the issue I opened at Apple as been closed and mark as duplicate of another bug they are tracking, probably means there is effectively a bug 😉

Hello David,

Engineering has determined that your bug report (40816482) is a duplicate of 39987152 and will be closed.

…

peterpeterparker on Jun 14, 2018

I can confirm that GET requests are working fine, but POST fails, too.

timbru31 on Jun 13, 2018

@mhartington I have build the same repo and invited you, let me know if everything is alright

IMPORTANT I discovered something really interesting while developing this sample repo, actually, Https GET queries are still fine with iOS v12 but I face problems with POST requests

GET = OK

const params: HttpParams = new HttpParams();
this.httpClient.get('https://example.com/route/', {params: params}).subscribe...

POST = KO

 let headers:HttpHeaders = new HttpHeaders();
 headers.append('Content-Type', 'application/json');
 this.httpClient.post('https://example.com/route/', {}, {headers: headers}).subscribe(....

Would be happy to hear if someone could confirm that

P.S.: I didn’t tried PUT and DELETE

peterpeterparker on Jun 12, 2018

Are there any other workarounds people have found for this issue? It’s definitely easier to have users upgrade but we have a set of users on 12.1.2 and 12.1.3 for which this issue is still happening pretty consistently.

devakone on Jan 26, 2019

Sounds good. it’s mahrtington on bitbucket as well.

mhartington on Jun 12, 2018