Re: [webkit-dev] Networking proxy on iOS

[Brady Eidson]

> On May 21, 2016, at 2:05 PM, Daniel Olegovich Lazarenko  
> wrote:
> 
> > We are exploring ways to restore that full functionality - 
> > https://bugs.webkit.org/show_bug.cgi?id=138169 
> > 
> 
> Having custom scheme protocols is important to me too. I didn't know that it 
> is broken with WKWebView. Do you know what exactly is broken?

From most developer’s perspective, what is broken is that their NSURLProtocol 
they can register in their “UI Process” that used to work in WK1 views no 
longer has any effect in WK2.

> 
> I thought that if you call [WKBrowsingContextController 
> registerSchemeForCustomProtocol:] with your scheme, then it works. When I 
> checked last (a year ago) it was implemented in a way that the 
> WebProcess/NetworkingProcess would pass a message to UIProcess, and handle 
> the network request in the UIProcess. Did it change?

That did not change.

But that mechanism was never API, and even as SPI it is formally deprecated.

> Assuming that registerSchemeForCustomProtocol still works the same way, you 
> basically state that you dislike the current solution (that does the work in 
> the UIProcess), and want to have a different architecture.
> 
> For custom networking or proxying you have to run the app-provided code. The 
> basic strategy I proposed was to run it in the app process (i.e. UIProcess). 
> Since you don't want any networking in UIProcess, it means that the app needs 
> to spawn a dedicated process to do custom networking. This process would run 
> app-specific code (including NSURLProtocol-s), and communicate by IPC with 
> the NetworkingProcess. Is this a kind of architecture you would like to have?

It’s not yet clear what the ideal architecture is, which is one of the reasons 
why the mentioned issued remains unresolved.

Thanks,
~Brady


> 
> 
> On Fri, May 20, 2016 at 5:58 PM, Brady Eidson  > wrote:
> 
>> On May 20, 2016, at 2:30 AM, Daniel Olegovich Lazarenko > > wrote:
>> 
>> Thank you for such a fast reply. That is amazing! :)
>> Back to questions...
>> 
>> > Are you primarily focused on a custom networking layer (e.g. your own HTTP 
>> > implementation?),
>> > or with custom protocol handling for non-http protocols?
>> 
>> I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but if 
>> there are any other widely used protocols that's also interesting. FTP 
>> support is not interesting for me. Do you have any other specific things in 
>> mind?
>> 
>> If there's a custom proprietary protocol that people handle in the app with 
>> their own code, for example, acme://acme.com:1234 , 
>> then proxying this thing is not very interesting to me, because it's very 
>> easy to proxy my own protocol handled by my own code. There's a case when 
>> "acme" is provided by some 3rd party, and the app author doesn't have the 
>> processing code. In such case it might be interesting to proxy it as well, 
>> but then again, I'm asking for a concrete example of such protocol (in 
>> WebKit context).
> 
> In a WebKit1 app (WebView on Mac, UIWebView on iOS), app authors were able to 
> use NSURLProtocol to override any scheme they wished.
> 
> While some such as yourself might’ve used it to override http from the 
> default handling, *many more* used it to implement custom protocols. e.g. 
> “acme://my-app-specific-url <>”
> 
> We are exploring ways to restore that full functionality - 
> https://bugs.webkit.org/show_bug.cgi?id=138169 
> 
> 
>> > You seem to dismiss the Networking process’ crash recovery aspect.
>> > "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?
>> 
>> Well, I'm not dismissing it, it's definitely a trade off that an app author 
>> will make by choosing to enable this option.
>> 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'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'm sure that you have your own crash analysis system with 
>> much more data.
> 
> Without getting in to specifics, the NetworkingProcess does crash.
> 
> And while the WebContent process does crash way more, it usually only effects 
> that one web page.
> 
> If networking code was back inside the UI Process, and it crashed, that takes 
> down the whole browser.
> 
> Doing so would be reverting towards the single process architecture of 
> yesteryear, n

Re: [webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

> We are exploring ways to restore that full functionality -
https://bugs.webkit.org/show_bug.cgi?id=138169

Having custom scheme protocols is important to me too. I didn't know that
it is broken with WKWebView. Do you know what exactly is broken?

I thought that if you call [WKBrowsingContextController
registerSchemeForCustomProtocol:] with your scheme, then it works. When I
checked last (a year ago) it was implemented in a way that the WebProcess/
NetworkingProcess would pass a message to UIProcess, and handle the network
request in the UIProcess. Did it change?

Assuming that registerSchemeForCustomProtocol still works the same way, you
basically state that you dislike the current solution (that does the work
in the UIProcess), and want to have a different architecture.

For custom networking or proxying you have to run the app-provided code.
The basic strategy I proposed was to run it in the app process (i.e.
UIProcess). Since you don't want any networking in UIProcess, it means that
the app needs to spawn a dedicated process to do custom networking. This
process would run app-specific code (including NSURLProtocol-s), and
communicate by IPC with the NetworkingProcess. Is this a kind of
architecture you would like to have?

Please don't get me wrong, I'm just trying to clarify that I understand you
correctly.

> Adding this “optional” networking mode would double certain testing
matrices
> and make development in this area (which there has been a lot of lately)
more difficult.

I totally believe that.
I hope that we eventually come to a solution that works well for you, and
that you could potentially approve and commit.



On Fri, May 20, 2016 at 5:58 PM, Brady Eidson  wrote:

>
> On May 20, 2016, at 2:30 AM, Daniel Olegovich Lazarenko 
> wrote:
>
> Thank you for such a fast reply. That is amazing! :)
> Back to questions...
>
> > Are you primarily focused on a custom networking layer (e.g. your own
> HTTP implementation?),
> > or with custom protocol handling for non-http protocols?
>
> I'm primarily concerned about HTTP and friends (HTTPS, SPDY, HTTP2), but
> if there are any other widely used protocols that's also interesting. FTP
> support is not interesting for me. Do you have any other specific things in
> mind?
>
> If there's a custom proprietary protocol that people handle in the app
> with their own code, for example, acme://acme.com:1234, then proxying
> this thing is not very interesting to me, because it's very easy to proxy
> my own protocol handled by my own code. There's a case when "acme" is
> provided by some 3rd party, and the app author doesn't have the processing
> code. In such case it might be interesting to proxy it as well, but then
> again, I'm asking for a concrete example of such protocol (in WebKit
> context).
>
>
> In a WebKit1 app (WebView on Mac, UIWebView on iOS), app authors were able
> to use NSURLProtocol to override any scheme they wished.
>
> While some such as yourself might’ve used it to override http from the
> default handling, *many more* used it to implement custom protocols. e.g. “
> acme://my-app-specific-url”
>
> We are exploring ways to restore that full functionality -
> https://bugs.webkit.org/show_bug.cgi?id=138169
>
> > You seem to dismiss the Networking process’ crash recovery aspect.
> > "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?
>
> Well, I'm not dismissing it, it's definitely a trade off that an app
> author will make by choosing to enable this option.
> 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'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'm sure that you have your own crash analysis system with
> much more data.
>
>
> Without getting in to specifics, the NetworkingProcess does crash.
>
> And while the WebContent process does crash way more, it usually only
> effects that one web page.
>
> If networking code was back inside the UI Process, and it crashed, that
> takes down the whole browser.
>
> Doing so would be reverting towards the single process architecture of
> yesteryear, not progressing away from it.
>
> Let's discuss the sandboxing a little bit. First of all, and correct me if
> I'm wrong: I thought that there's no 3rd party code execution in the
> networking process,
>
>
> Currently, there is no 3rd party code execution in the networking process.
>
> and all the JS execution happens inside the WebProcess.
>
>
> That’s correct, but I’m not necessarily talking about JS.
>
> The code that w