Time to throw in my two bits:
First, the environment variable HTTP_PROXY is very common... I find lots of
applications use it as the default proxy settings. You can put it in URL
format too: "protocol://username:password_at_server:port/". Mine is as simple
as: "http://webdevel:3128/" for a local squid server with no login. Where
users are behind a proxy, chances are, http_proxy is already set for use
with the other applications they use.
If not, a simple 4 parameter configuration as you describe below could
replace or override that environment variable. Or one parameter in the
above format.
As for command line, a wget/lynx style option to ignore the env var might
help.
...from the wget man page:
-Y on/off --proxy=on/off
Turn proxy on or off. The proxy is on by default if the appropriate
environmental variable is defined.
Or, in the rc file:
http_proxy = string
Use the string as HTTP proxy, instead of the one specified in environment.
That sound's like a good strategy. Use http_proxy unless:
a) a no proxy option is specified on the command line
b) it's turned off in the per-project config
c) it's overridden to a new proxy in the per-project config
Second - this is a major need for those of us trapped behind corporate
proxies. It's one of the limiting factors that CVS has. Anonymous (non-SSH
based) access is difficult from behind a proxy.
Glad to finally start contributing,
~Jon
PS - An introduction is probably in order...
I've been on this list for just a few weeks. I'm a heavy CVS user at work,
maintaining all my projects and the company web site (dev and production)
in CVS. I experience daily aggravation with some of the limitations SVN is
aiming to eliminate - moving a file from one directory to another, for
example. Hence, my interest in SVN ;-)
I'm lurking for now, but my involvement will increase dramatically once I
get DSL at my new place - just moved and feeling very internet deprived.
--On Thursday, November 01, 2001 8:08 AM +0100 Daniel Stenberg
<daniel@haxx.se> wrote:
> On Wed, 31 Oct 2001, Greg Stein wrote:
>
>> There have been a couple different approaches to handling proxies.
>> Honestly, I'm not really sure what is "best".
>>
>> I know that an environment variable is not preferred, unless there is a
>> hugely widespread, typical usage (like EDITOR).
>
> ... and there just isn't one that widespread.
>
>> We just don't want to use environment variables, if at all possible.
>
> IMO, we could support the ones lynx, wget and others use, but that would
> be an additional feature and should most likely be done purely by the
> client code and we shouldn't depend on it.
>
>> Second, we need to consider that proxies require (at least) four more
>> pieces of information:
>>
>> 1) proxy host
>> 2) proxy port (default to 80 or whatever)
>> 3) proxy username
>> 4) proxy password
>>
>> Somehow, we need to be able to specify any/all of these. Of course, some
>> can go in the .svnrc file, but they could also be needed on a per-project
>> basis.
>
> I could immediately think of situtations when they will be needed on a
> per-project basis:
>
> Like the situation on my current work place. We have the whole internal
> source repository on the internal network, but we use a HTTP proxy to
> access the web. So if I wanna use svn for both inside work sources and
> remote source, I need to set a proxy for for the remote sources only.
>
> More specificly, they actually are on a per-host basis depending on where
> the host is that we get the sources from.
>
> So, either we let the client keep a list with hosts that "don't use the
> default rule", or we add command line flags that says to alter the
> default. Then we can have the default proxy informations in the .svnrc
> file. If the default would be to not use a proxy, we need to be able to
> specify all these four different variables on the command line...
>
> --
> Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
> ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:47 2006