So this is a bug of Chrome on iOS which we don't have expertise. I would appreciated if Chrome on iOS team could triage this issue.

Reporter: Can you tell us if Safari has the same problem?

No Safari does not seem to have the same problem

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

eugenebut@ can you please take a look?

andreas@, does this bug reproducible with Safari and/or Firefox on iOS?

I’ve tested on safari and it doesn’t seem to have the problem. Haven’t tried it on Firefox

Safari and stock WKWebView may have different behavior. So comparing the behavior with Firefox could be really helpful.

I would consider it a bug in any case.
I found it while comparing analytics data sent from clients using different methods (xhr and sendBeacon). Generally it seems it worked with sendBeacon except for chrome and facebooks and twitters in app browsers on iOS. We’re talking about millions of requests and my theory is that it works when the xhr request happens before the sendBeacon one so removing the old method with xhr and only use sendBeacon would mean even less if any data coming in from chrome on iOS. Now I don’t know how big Firefox on iOS is in our user base is but from what I remember I didn’t se any Firefox user agent showing those problems at least not in the same numbers.

I tried firefox on iOS and actually firefox doesn't send either the xhr or the sendBeacon.

I also realised that point 5 in the reproduce steps is wrong, it should be 
$ws --https --port 8000

Thanks a lot for the update! I would recommend filing a WebKit bug, as it seem like a problem with System's WKWebView component:
https://bugs.webkit.org/enter_bug.cgi?product=WebKit

Danyao, is this something that we could fix in WebKit?

I've also noticed this. 

It works on: iPhone Safari, iPhone Puffin, iPad Chrome, Android Chrome and desktop browsers (macOS Chrome, macOS Safari and macOS Firefox).

It fails on: iPhone Chrome, iPhone Firefox, iPhone Edge and iPhone DuckDuckGo.

This is a bug in the way that certificate validation is handled for beacon requests in WebKit.

WebKit::PingLoad::didReceiveChallenge just rejects the certificate and cancels the request (regardless of the actual validity of the certificate).

So the beacon only works if some other type of request has been made to the same domain and accepted the certificate, so that the PingLoad (that is, the beacon load request) never receives a challenge.

Safari doesn't run into this problem, because it opts-out (using the _WKProcessPoolConfiguration::_setCanHandleHTTPSServerTrustEvaluation private API) of being involved in certificate validation, leaving it up to the OS to deal with.

More specifically, in [WKNetworkSessionDelegate URLSession:task:didReceiveChallenge:completionHandler], Safari will early-out at the 'if (!_session->networkProcess().canHandleHTTPSServerTrustEvaluation())' check, but other WKWebView embedders will go down the "networkDataTask->didReceiveChallenge()" path, winding up in PingLoad::didReceiveChallenge.

I'll file a WebKit bug for this and look into a proper fix there.

Thanks for looking into this and explaining the problem ajuma@chromium.org! :)

This is now fixed in WebKit: https://bugs.webkit.org/show_bug.cgi?id=193508