On Fri, Sep 14, 2012 at 01:22:03PM +0200, Johan Corveleyn wrote:
> On Thu, Sep 13, 2012 at 4:50 PM, Josh Triplett <josh_at_joshtriplett.org> wrote:
> > On Thu, Sep 13, 2012 at 08:03:06AM -0400, C. Michael Pilato wrote:
> ...
> >> - While your approach was the super simple one to take, how do we feel about
> >> the fact that this would cause all programs which linked against
> >> Subversion's libs to start noticing those environment variables which are
> >> really kind meant to be specific to just the command-line clients. In the
> >> past, I (and others) have gone on record against such things. Perhaps a
> >> better approach would be for 'svn' -- or one of the common svn_cmdline_*
> >> functions in libsvn_subr -- to parse the env variables and use the results
> >> to override the parsed runtime configuration values in the svn_config_t
> >> structures that get passed all over the place. I dunno.
> >
> > Why should only the command-line clients notice those environment
> > variables? If someone has http_proxy set, and runs some graphical
> > subversion client using libsvn, that client ought to use the proxy as
> > well. I'd suggest that libsvn should always respect system proxy
> > settings, rather than forcing the caller to do extra (duplicate) work to
> > parse and set the proxy.
>
> I'm not an expert in proxy stuff, but can you also set
> proxy-exceptions, and a proxy-username and password via those
> environment variables (or setting a proxy configuration file (pac))?
> If you go the route of reading the environment, I think you should
> also be able to do those things.
You can set a username and password in the URL, which works with the
patch I submitted:
http_proxy=http://user:pass@proxy.example.com:port/
The somewhat less common "no_proxy" environment variable exists to set
up proxy exceptions, but it has a less standardized syntax that does not
use full URLs; I've seen things like no_proxy=.example.com ,
no_proxy=example.com , no_proxy=*.example.com,*.other.example.net , and
a few other variations. Adding a patch for it (and covering those
variations) seems feasible, but I'd really like to get this basic
support in first before going for further enhancements. :)
- Josh Triplett
Received on 2012-09-14 19:49:28 CEST