[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160519/19d666b8/attachment.html>