[Qtwebengine] Add way to override host resolution

[Allan Jensen]

Hi,

That sounds like a great idea, and useful for more than just you. So if you 
submit it I will definitely give a look, and I think you are right, that it 
should be possible to do without patching Chromium. We have a chance to set a 
host-resolver in ProfileIoDataQt, so it should be possibly to override. 

One issue you might run into though is bridging threads. Typically we assume 
our API is accessed from the main thread or unknown user threads, where 
Chromium will likely access the host resolver from the IO thread.

Btw. would you be able to implement this using Chrome extensions if we had 
support for that? We got most of the infrastructure for that into 5.13, so it 
is likely we can enable a lot of extension features for 5.14.

Best regards
'Allan

On Thursday, 14 February 2019 16:25:23 CET Manuel Peinado wrote:
> Hi all,
> 
> We have this app we’re working on at Plex that’s written in QML and makes
> heavy use of WebEngineView. In order to implement our secure connections
> feature (see
> https://support.plex.tv/articles/206225077-how-to-use-secure-server-connecti
> ons/) we would need to hook into Chromium's DNS resolution. The goal is
> pretty simple, basically detect if the host has a particular structure and
> resolve it to a custom IP in case it does.
> 
> So assuming Qt had support for this, we would be doing something like the
> following:
> 
> 
> QQuickWebEngineProfile* webEngineProfile = ...;
> webProfile->setHostResolver(new CustomHostResolver());
> 
> Where CustomHostResolver would implement an interface similar to the
> existing QWebEngineUrlRequestInterceptor:
> 
> class CustomHostResolver : public QtWebEngineHostResolver
> {
>  Q_OBJECT
> 
> public:
> 
>  void resolveHost(QWebEngineHostResolutionInfo& info) override
>  {
>    if (info.host == "special host name")
>    {
>      info.resolveHostTo("custom IP");
>      return;
>    }
> 
>    // If we don't modify "info" then the host gets resolved
>    // using the default, DNS based, path.
>  }
> };
> 
> There is no support at the moment for any of this in QtWebEngine, so we
> would have to add it ourselves. And here's the question: if we create a PR
> that implements this, would it have any chance of getting reviewed and
> ultimately accepted? Just want to make sure it stands a chance before we
> spend a bunch of time working on it.
> 
> (I've studied the underlying code and think we would be able to implement
> what we need without requiring any patches to Chromium, which should
> improve the chances that the PR succeeds right?)