<div dir="ltr">Thank you for such a fast reply. That is amazing! :)<div>Back to questions...<br><div><br></div><div><div style="font-size:12.8px">&gt; Are you primarily focused on a custom networking layer (e.g. your own HTTP implementation?),</div><div style="font-size:12.8px">&gt; or with custom protocol handling for non-http protocols?</div><div><br></div><div>I&#39;m primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but if there are any other widely used protocols that&#39;s also interesting. FTP support is not interesting for me. Do you have any other specific things in mind?</div><div><br></div><div>If there&#39;s a custom proprietary protocol that people handle in the app with their own code, for example, acme://<a href="http://acme.com:1234">acme.com:1234</a>, then proxying this thing is not very interesting to me, because it&#39;s very easy to proxy my own protocol handled by my own code. There&#39;s a case when &quot;acme&quot; is provided by some 3rd party, and the app author doesn&#39;t have the processing code. In such case it might be interesting to proxy it as well, but then again, I&#39;m asking for a concrete example of such protocol (in WebKit context).</div></div><div><br></div><div><span style="font-size:12.8px">&gt; I’m not sure it’s useful for WebKit to spend energy testing and maintaining a mechanism</span></div><div><span style="font-size:12.8px">&gt; that *only* allows for HTTP-handling replacement and doesn’t also allow for</span></div><div><span style="font-size:12.8px">&gt; the oft-requested feature of custom protocol handling.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I understand your concerns. Let&#39;s say that we forget the httpProxy solution for now, and discuss the 2nd UIProcess-networking approach a bit more.</span></div><div><span style="font-size:12.8px"><br></span></div><div><div style="font-size:12.8px">&gt; You seem to dismiss the Networking process’ crash recovery aspect.</div><div style="font-size:12.8px"><span style="font-size:12.8px">&gt;</span><span style="font-size:12.8px"> </span>&quot;because in practice we know that most of the crashes happen in the WebProcess parts”.</div><div style="font-size:12.8px"><span style="font-size:12.8px">&gt;</span><span style="font-size:12.8px"> </span>I’m curious what data you’re using to make that claim?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Well, I&#39;m not dismissing it, it&#39;s definitely a trade off that an app author will make by choosing to enable this option.</div><div style="font-size:12.8px">The data comes from our web browser apps. We certainly see networking faults, but in total it was usually a minor part of all the WebKit crashes. To not sound subjective, I&#39;ve looked through our current app version, which already has enough data to judge, and in the top WebKit crashes there are none in the network code. Most are crashes in JavaScriptCore, DOM and graphics subsystems. This is the experience we have over many versions and years of service. I might be able to show you the data in private if you want, although I&#39;m sure that you have your own crash analysis system with much more data.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><span style="font-size:12.8px">&gt; The Networking process provides significant benefit unrelated to crash recovery</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">&gt; that should not be abandoned for convenience sake. e.g. Sandboxing.</span><br></div><div style="font-size:12.8px"><span style="font-size:12.8px">&gt; Especially when moving the networking to the UI process</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">&gt;</span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">would also end up moving 3rd party code execution into the UI process,</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">&gt;</span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">this seems like an unacceptable regression.</span><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style=""><span style="font-size:12.8px">Let&#39;s discuss the sandboxing a little bit. First of all, and correct me if I&#39;m wrong: I thought that there&#39;s no 3rd party code execution in the networking process, and all the JS execution happens inside the WebProcess. The code that we want to run is our own code that we control that we implement in a safe and secure manner. In this sense it&#39;s no less secure. In the end we are always protected by the iOS/Mac sandbox. M</span><span style="font-size:12.8px">aybe I&#39;m wrong about JS here, or d</span><span style="font-size:12.8px">o you have some other use case in mind?</span></div><div style=""><span style="font-size:12.8px"><br></span></div><div style=""><span style="font-size:12.8px">&gt; Debugging the multi process architecture of WebKit2 </span><br></div><div style=""><span style="font-size:12.8px">&gt; has not gotten any harder in years, </span><span style="font-size:12.8px">active developers have all adapted, </span></div><div style=""><span style="font-size:12.8px">&gt; and new developers tend to pick it up pretty quickly. </span><span style="font-size:12.8px">This is not a useful point.</span></div><div style=""><span style="font-size:12.8px"><br></span></div><div style=""><span style="font-size:12.8px">I&#39;m sorry that you are rejecting this. Of course you can adapt to that, but it inevitably has a steeper learning curve, and takes longer time. Many app developers come from a single-process background and</span><span style="font-size:12.8px"> find multi-process debugging much harder.</span><span style="font-size:12.8px"> Often i</span><span style="font-size:12.8px">t&#39;s a real challenge to understand what&#39;s going on. I&#39;m sure that you in your team have multiple stories that show how non-trivial it is, and tricks about dealing with it. Nevertheless, I agree, it&#39;s not a decisive point.</span></div><div style=""><span style="font-size:12.8px"><br></span></div><div style=""><span style="font-size:12.8px"><br></span></div><span class="im" style="font-size:12.8px"></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 19, 2016 at 6:43 PM, Brady Eidson <span dir="ltr">&lt;<a href="mailto:beidson@apple.com" target="_blank">beidson@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On May 19, 2016, at 8:41 AM, Daniel Olegovich Lazarenko &lt;<a href="mailto:danielo@opera.com" target="_blank">danielo@opera.com</a>&gt; wrote:</div><div><div dir="ltr"><div><br></div><div>I&#39;d like to ask your for advice about implementation of a custom networking layer</div></div></div></blockquote><div><br></div></span>Are you primarily focused on a custom networking layer (e.g. your own HTTP implementation?), or with custom protocol handling for non-http protocols?</div><div><br><blockquote type="cite"><div><div dir="ltr"><div>...with WKWebView on iOS.</div></div></div></blockquote><div><br></div>WKWebView is an API that ships on both OS X and iOS. When a design aspect of it affects both platforms (such as the networking behavior), we must consider both platforms.</div><div><span class=""><br><blockquote type="cite"><div dir="ltr"><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></blockquote><div><br></div></span><div><div>I’m not sure it’s useful for WebKit to spend energy testing and maintaining a mechanism that *only* allows for HTTP-handling replacement and doesn’t also allow for the oft-requested feature of custom protocol handling.</div></div></div><div><span class=""><br><blockquote type="cite"><div dir="ltr"><div>Now I&#39;m again looking for a better solution.</div><div><div>I&#39;d really like to discuss it with somebody responsible, </div></div></div></blockquote><div><br></div></span>There is no single person responsible; the project works largely on consensus. When dealing with platform specific concerns such as this, it works on consensus of the platform owners.</div><div><br></div><div>That said, I have been the primary caretaker of the Networking process since it’s inception, as well one of the primary caretakers of Mac/iOS networking in general for many years, so I’ll share my thoughts below.</div><div><br><blockquote type="cite"><div><div dir="ltr"><span class=""><div>There&#39;s currently 2 solutions I&#39;m weighting:</div></span><div><ol><li>Pass and use NetworkProcessCreationParameters.httpProxy to NSURLSessionConfiguration (in NetworkSession and maybe other places). 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&#39;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.</li></ol></div></div></div></blockquote><div>While ToT WebKit contains an NSURLSession-based networking implementation for Mac/iOS, it also still contains an NSURLConnection implementation, which is unaffected by NSURLSession considerations.</div><div><br></div><div>That a solution doesn’t work on all supported platforms is not a deal breaker, but it certainly makes it less interesting than one that does.</div><div><br></div><div>HTTPS losing reliability is likely an unacceptable red flag. </div><div><br></div><div><div><div><div>I’m not sure it’s useful for WebKit to spend energy testing and maintaining a mechanism that *only* allows for HTTP-handling replacement and doesn’t also allow for the oft-requested feature of custom protocol handling.</div></div></div></div><span class=""><blockquote type="cite"><div><div dir="ltr"><div><ol start="2"><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></div></div></blockquote></span><blockquote type="cite"><div><div dir="ltr"><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.</div></div></div></blockquote><div><br></div><div>You seem to dismiss the Networking process’ crash recovery aspect. &quot;because in practice we know that most of the crashes happen in the WebProcess parts”.  I’m curious what data you’re using to make that claim?</div><span class=""><div><br></div><div><blockquote type="cite"><div dir="ltr"><div> I don&#39;t see any other significant downsides of having the UIProcess handling networking.</div></div></blockquote><br></div></span><div>The Networking process provides significant benefit unrelated to crash recovery that should not be abandoned for convenience sake. e.g. Sandboxing.</div><div><br></div><div>Especially when moving the networking to the UI process would also end up moving 3rd party code execution into the UI process, this seems like an unacceptable regression.</div><span class=""><div><br></div><div><blockquote type="cite"><div dir="ltr"><div>In addition it can simplify the NetworkProcess debugging.</div></div></blockquote><br></div></span><div>Debugging the multi process architecture of WebKit2 has not gotten any harder in years, active developers have all adapted, and new developers tend to pick it up pretty quickly. This is not a useful point.</div><div><br></div><div>Thanks,</div><div>~Brady</div><div><br></div></div></div></blockquote></div><br></div>