Re: [webkit-dev] Networking proxy on iOS

[Brady Eidson]

> On May 19, 2016, at 8:41 AM, Daniel Olegovich Lazarenko  
> wrote:
> 
> I'd like to ask your for advice about implementation of a custom networking 
> layer

Are you primarily focused on a custom networking layer (e.g. your own HTTP 
implementation?), or with custom protocol handling for non-http protocols?

> ...with WKWebView on iOS.

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.

> Our current solution is based on NSURLProtocol, and the issues we had with it 
> in 2014 are unresolved:
> https://bugs.webkit.org/show_bug.cgi?id=137302 
> 
> https://bugs.webkit.org/show_bug.cgi?id=138131 
> 
> 
> It was kind of a shoehorn hack, and so it was rejected by Benjamin Poulain 
> and Alexey Proskuryakov among other reviewers.

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.

> Now I'm again looking for a better solution.
> I'd really like to discuss it with somebody responsible,

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.

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.

> There's currently 2 solutions I'm weighting:
> 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'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.
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.

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.

HTTPS losing reliability is likely an unacceptable red flag. 

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.
> 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).
> 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.

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?

>  I don't see any other significant downsides of having the UIProcess handling 
> networking.

The Networking process provides significant benefit unrelated to crash recovery 
that should not be abandoned for convenience sake. e.g. Sandboxing.

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.

> In addition it can simplify the NetworkProcess debugging.

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.

Thanks,
~Brady

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

Hello,

I'd like to ask your for advice about implementation of a custom networking
layer with WKWebView on iOS.

Our current solution is based on NSURLProtocol, and the issues we had with
it in 2014 are unresolved:
https://bugs.webkit.org/show_bug.cgi?id=137302
https://bugs.webkit.org/show_bug.cgi?id=138131

It was kind of a shoehorn hack, and so it was rejected by Benjamin Poulain
and Alexey Proskuryakov among other reviewers.

Now I'm again looking for a better solution.
I'd really like to discuss it with somebody responsible, reach common
understanding and agreement, and attack this problem.

There's currently 2 solutions I'm weighting:

   1. Pass and use NetworkProcessCreationParameters.httpProxy to
   NSURLSessionConfiguration (in NetworkSession and maybe other places).
   2. 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).

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.

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.

--
With best regards,
Daniel Lazarenko
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev