Created attachment 416705 [details] This is a screenshot of the sample code to solve this problem, please be sure to check. When using the instantiated object of WKWebView to load the URL through `func load(_ request: URLRequest)`, we create a URLRequest object and add some custom header fields to it, but in our production environment, about Among the requests of 1 million users, the result obtained by adding Log information to this judgment condition is that the problem of the loss of this customerHeaderKey will occur approximately 4000 times per hour. This problem occurs on multiple iOS versions and multiple iPhone models. When we call the .load(request) method to load this URL, in the `decidePolicyFor navigationAction` proxy method callback, we pass request.value(forHTTPHeaderField: "customHeaderKey") == nil to determine whether the value of customerHeaderKey exists; we self The result of the test is that it can run correctly in debug mode, and the value of customerHeaderKey always exists. However, in the production environment, a few users will lose headers on their iPhones, not only this customHeaderKey, but also other httpHeader fields. Later, we tried to fix this problem with the following code. After verification, this method is effective and can reduce the probability of this header loss problem by more than 90%, from more than 4000 per hour to about 100 times per hour. But despite this, this problem has not been solved fundamentally, because some users still have this problem through multiple reload methods (we try to set maxReloads>3 times and the effect is basically the same). So we now suspect that it is a bug in WebKit, but there is no fundamental basis. Please help check the root cause of this problem. thank you very much!
This is the first time I have submitted a bug. If there are omissions and errors, please understand! English is not my native language; please excuse typing errors.
<rdar://problem/72737107>
Thanks for filing, if possible please capture a sysdiagnose from an affected device after reproducing the issue and note as precise a timestamp as possible.
This issue appeared on the user’s iPhone. Unfortunately, this problem was not reproduced on our test machine, so it is difficult to get the sysdiagnose data; let’s think about whether there are other ways.
I got back to you on commont 4, thanks!