[Webkit-unassigned] [Bug 220113] New: [iOS][WebView] HttpHeader filed is missing in the decidePolicyFor delegate method of WebView

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 23 03:25:19 PST 2020


https://bugs.webkit.org/show_bug.cgi?id=220113

            Bug ID: 220113
           Summary: [iOS][WebView] HttpHeader filed is missing in the
                    decidePolicyFor delegate method of WebView
           Product: WebKit
           Version: Other
          Hardware: iPhone / iPad
                OS: All
            Status: NEW
          Severity: Major
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: hi at jinxiansen.com

Created attachment 416705

  --> https://bugs.webkit.org/attachment.cgi?id=416705&action=review

example code.

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!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201223/4b726096/attachment-0001.htm>


More information about the webkit-unassigned mailing list