[GTK] Use 'http_proxy' environment variable behind proxy circumstance

• Component: WebKitGTK
• Status: RESOLVED INVALID

[Joonghun Park]

When using GTK Minibrowser behind proxy environment, use 'http_proxy' environment variable not to be blocked.

[Joonghun Park]

Created attachment 277210 [details]
Use http_proxy behind proxy wall

[Carlos Garcia Campos]

Comment on attachment 277210 [details]
Use http_proxy behind proxy wall

View in context: https://bugs.webkit.org/attachment.cgi?id=277210&action=review

I think we don't this because the gnome proxy resolver already does this for us. I guess this doesn't work in non gnome environments, maybe we should try to detect that or something.

> Source/WebCore/platform/network/soup/SoupNetworkSession.cpp:232
> -#if PLATFORM(EFL)
> +#if PLATFORM(EFL) || PLATFORM(GTK)

If we do this, we should just remove the ifdefs

> Source/WebCore/platform/network/soup/SoupNetworkSession.cpp:233
>      // Only for EFL because GTK port uses the default resolver, which uses GIO's proxy resolver.

And this comment would not make sense anymore.

[Joonghun Park]

Created attachment 277236 [details]
Remove unneeded PLATFORM ifdefs and annotation

[Carlos Alberto Lopez Perez]

(In reply to comment #2)
> I think we don't this because the gnome proxy resolver already does this for
> us. I guess this doesn't work in non gnome environments, maybe we should try
> to detect that or something.

This feature has been requested on the past, see for example bug 128674

I think we should have our own way (be it via en environment variable or via new API) to set the proxy settings. IMHO WebKitGTK+ should not rely on GNOME for working, or have less features outside of a GNOME environment.

Personally I find interesting the environment variable way as it allows to change the settings at runtime easily for any WebKitGTK+ application (even if the author of such application didn't thought about using a proxy).

The environment variable http_proxy is somehow standard and is honored by several utilities like wget or curl. So is expected that this variable is already set to the right value on any machine that access Internet via a proxy.

On the other hand I also see adding new API to set this setting interesting for anyone that wants to control the proxy settings directly on its own application.

So maybe we can have the 3 ways of setting a proxy? My doubt is which one(s) should have preference in case of more than one being defined.

[Joonghun Park]

Comment on attachment 277236 [details]
Remove unneeded PLATFORM ifdefs and annotation

Overall comments

[Joonghun Park]

(In reply to comment #4)
> (In reply to comment #2)
> > I think we don't this because the gnome proxy resolver already does this for
> > us. I guess this doesn't work in non gnome environments, maybe we should try
> > to detect that or something.
> 
> This feature has been requested on the past, see for example bug 128674
> 
> I think we should have our own way (be it via en environment variable or via
> new API) to set the proxy settings. IMHO WebKitGTK+ should not rely on GNOME
> for working, or have less features outside of a GNOME environment.
> 
> Personally I find interesting the environment variable way as it allows to
> change the settings at runtime easily for any WebKitGTK+ application (even
> if the author of such application didn't thought about using a proxy).
> 
> The environment variable http_proxy is somehow standard and is honored by
> several utilities like wget or curl. So is expected that this variable is
> already set to the right value on any machine that access Internet via a
> proxy.
> 
> On the other hand I also see adding new API to set this setting interesting
> for anyone that wants to control the proxy settings directly on its own
> application.
> 
> So maybe we can have the 3 ways of setting a proxy? My doubt is which one(s)
> should have preference in case of more than one being defined.

I agree with both of you. It seems that more independent way would be good rather than using GNOME API here.

[Michael Catanzaro]

The problem with this patch is that it unconditionally replaces the default GProxyResolver with a GSimpleProxyResolver. This is going to break all proxy settings for anyone not using the env variables, or for anybody using a custom setup with a homebrewed GProxyResolver. (Note this is a Gio extension point; you can inject your own GProxyResolver at runtime with a shared object to be dlopened.) So this needs to be done only conditionally, if the default GProxyResolver is somehow unsuitable.

But I'm not quite sure what that condition is, or why this is necessary. As far as I can tell, when using glib-networking (I presume you're using glib-networking), then GLibProxyResolver will be used by default outside of GNOME and Ubuntu, otherwise GProxyResolverGnome will be used. But GLibProxyResolver gets proxy settings from libproxy. I would think libproxy would be smart enough to check these env variables? I wonder, what type of GProxyResolver are you actually getting?

(In reply to comment #4)
> I think we should have our own way (be it via en environment variable or via
> new API) to set the proxy settings. IMHO WebKitGTK+ should not rely on GNOME
> for working, or have less features outside of a GNOME environment.

Agreed, but we need to understand why it's currently not working.

> On the other hand I also see adding new API to set this setting interesting
> for anyone that wants to control the proxy settings directly on its own
> application.

Agreed. In the case the application uses such API, then it would always make sense to overwrite the default GProxyResolver with a GSimpleProxyResolver. But this is a separate issue, not something to be resolved in this bug.

> So maybe we can have the 3 ways of setting a proxy? My doubt is which one(s)
> should have preference in case of more than one being defined.

Well the API should take precedence over anything else.

[Joonghun Park]

(In reply to comment #7)
> The problem with this patch is that it unconditionally replaces the default
> GProxyResolver with a GSimpleProxyResolver. This is going to break all proxy
> settings for anyone not using the env variables, or for anybody using a
> custom setup with a homebrewed GProxyResolver. (Note this is a Gio extension
> point; you can inject your own GProxyResolver at runtime with a shared
> object to be dlopened.) So this needs to be done only conditionally, if the
> default GProxyResolver is somehow unsuitable.
> 
In my case, I'm using Ubuntu 15.10, and without this patch gtk minibrowser cannot access to Internet for now. Maybe I have to take a look which condition could be put in here.

> But I'm not quite sure what that condition is, or why this is necessary. As
> far as I can tell, when using glib-networking (I presume you're using
> glib-networking), then GLibProxyResolver will be used by default outside of
> GNOME and Ubuntu, otherwise GProxyResolverGnome will be used. But
> GLibProxyResolver gets proxy settings from libproxy. I would think libproxy
> would be smart enough to check these env variables? I wonder, what type of
> GProxyResolver are you actually getting?
> 
FYI, when I looked into the libproxy source in here,
https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_envvar.cpp
I found libproxy is smart enough to figure out what value the environment variable holds. And Ubuntu uses glib-networking, and it uses GproxyResolver as you said, so I think that's the actually one I got.

> (In reply to comment #4)
> > I think we should have our own way (be it via en environment variable or via
> > new API) to set the proxy settings. IMHO WebKitGTK+ should not rely on GNOME
> > for working, or have less features outside of a GNOME environment.
> 
> Agreed, but we need to understand why it's currently not working.
> 
That's the point. It would be good to know why it is not working with proxy env in Ubuntu 15.10 in my case.

> > On the other hand I also see adding new API to set this setting interesting
> > for anyone that wants to control the proxy settings directly on its own
> > application.
> 
> Agreed. In the case the application uses such API, then it would always make
> sense to overwrite the default GProxyResolver with a GSimpleProxyResolver.
> But this is a separate issue, not something to be resolved in this bug.
> 
> > So maybe we can have the 3 ways of setting a proxy? My doubt is which one(s)
> > should have preference in case of more than one being defined.
> 
> Well the API should take precedence over anything else.