Re: [PATCH] Add support for http_proxy and https_proxy environment variables

On 25.09.2012 16:37, C. Michael Pilato wrote:
> On 09/17/2012 09:34 PM, Bert Huijben wrote:
>> On Windows this isn't the normal way to fetch the system wide proxy, nor
>> is it on the Mac. Adding environment flags to GUI applications there is
>> certainly *not* the right way to look at this problem. The linux specific
>> environment variable solution might apply to a linux gui, but not to a
>> Windows gui or a Windows/Mac shell or application extension.
>>
>> My earlier suggestion was to use libproxy, as that handles the normal
>> settings on all these platforms. On Linux it appears to use these proxy
>> environment variables (and a few others) as that appears to be the common
>> way to configure a proxy there, while on the Mac and Windows it properly
>> looks at the system proxy settings. It also handles corner cases like the
>> support for ignoring proxies for specific hosts.
>>
>> As libproxy is LGPL I don't think we can add it as an explicit
>> dependency, but adding it as an optional dependency would be a proper
>> solution. When encapsulated properly we can also add specific
>> implementations for other platforms ourselves. (Windows XP and later
>> appear to have a standard API that handles all kinds of proxies,
>> including pac files which would require some Mozilla components via
>> libproxy)
> +1 on the optional libproxy dependency. That makes great sense to me.
>
> However ... since the env-var stuff is *relatively* straightforward, would
> we be interested in/willing to *also* implement that (or a subset thereof)
> directly in our codebase for non-Windows, non-Mac use only? Or is that just
> begging to confuse our users?

If the env-var parsing is implemented in a way that is compatible with
libproxy, and it's disabled and completely replaced by libproxy when the
latter is enabled/available, then sure, there's no reason not to have
both. As long as someone is prepared to maintain both.

But if the proxy-detection behaviour changes noticeably when switching
from the built-in implementation to what libproxy gives us (always
remembering that libproxy will have a superset of the features), then
I'd think twice about such a two-pronged approach.

-- Brane

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download