On Fri, Sep 14, 2012 at 01:22:03PM +0200, Johan Corveleyn wrote: > On Thu, Sep 13, 2012 at 4:50 PM, Josh Triplett <j...@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:p...@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
