[webkit-dev] Networking proxy on iOS

[Daniel Olegovich Lazarenko]

There's another solution I'd like to point out.
The idea is to take the networking XPC service ID from NSUserDefaults.
That would technically make it possible to substitute the whole networking
process with a custom process.
The caveat here is that XPC is a private API on iOS, so it's not allowed to
do that.
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.

On Thu, May 19, 2016 at 5:41 PM, Daniel Olegovich Lazarenko <
danielo at opera.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160525/0b9992ee/attachment.html>