<div dir="ltr">There's another solution I'd like to point out.<div>The idea is to take the networking XPC service ID from NSUserDefaults.</div><div>That would technically make it possible to substitute the whole networking process with a custom process.</div><div>The caveat here is that XPC is a private API on iOS, so it's not allowed to do that.</div><div>On the other hand the good side about this solution is that the WebKit's own networking process would still be separate and free from any app code, so for example, the crash responsibility separation would still work, and the WebKit team won't have to deal with any more testing configurations.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 19, 2016 at 5:41 PM, Daniel Olegovich Lazarenko <span dir="ltr"><<a href="mailto:danielo@opera.com" target="_blank">danielo@opera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I'd like to ask your for advice about implementation of a custom networking layer with WKWebView on iOS.</div><div><br></div><div>Our current solution is based on NSURLProtocol, and the issues we had with it in 2014 are unresolved:</div><div><a href="https://bugs.webkit.org/show_bug.cgi?id=137302" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=137302</a><br></div><div><a href="https://bugs.webkit.org/show_bug.cgi?id=138131" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=138131</a><br></div><div><br></div><div>It was kind of a shoehorn hack, and so it was rejected by Benjamin Poulain and Alexey Proskuryakov among other reviewers.</div><div><br></div><div>Now I'm again looking for a better solution.</div><div><div>I'd really like to discuss it with somebody responsible, reach common understanding and agreement, and attack this problem.</div></div><div><br></div><div>There's currently 2 solutions I'm weighting:</div><div><ol><li>Pass and use NetworkProcessCreationParameters.httpProxy to NSURLSessionConfiguration (in NetworkSession and maybe other places).</li><li>Add a new mode to the NetworkProcess, which would do all networking in UIProcess (instead of spawning a new process). A mode would be optional and controlled with some configuration setting (or NSUserDefaults).</li></ol><div>The httpProxy solution is easy to implement and would look clean design-wise. It would let us spawn an HTTP proxy on localhost and filter the traffic there. There might be some complications, because it's not fully transparent to the client side. For example HTTPS will have issues. All in all this could be a fine short-term solution.<br></div></div><div><br></div><div>The UIProcess solution is harder to implement, and it will affect more code. It is somewhat controversial. One of the reasons of splitting out a NetworkProcess was to have it respawn after crashes. Nevertheless we can take this risk, because in practice we know that most of the crashes happen in the WebProcess parts. I don't see any other significant downsides of having the UIProcess handling networking. To me this seems like a better choice than httpProxy, because this way we avoid unnecessary data passing back and forth. We get more control, because it's transparent. In addition it can simplify the NetworkProcess debugging.</div><div><br></div><div>--<br></div><div>With best regards,</div><div>Daniel Lazarenko</div><div><br></div></div>
</blockquote></div><br></div></div></div>