You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Jonathan M. Manning" <jm...@alisa-jon.net> on 2001/11/01 17:50:33 UTC

Re: proxy support

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@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 
<da...@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

Re: proxy support

Posted by Daniel Stenberg <da...@haxx.se>.
On Thu, 1 Nov 2001, Jonathan M. Manning wrote:

> First, the environment variable HTTP_PROXY is very common...

Uh, you mean 'http_proxy' (lowercase), right? Environment variables prefixed
with HTTP_ (uppercase) gets set in CGI environments so you should never use
them otherwise, as using such a program within a CGI script would otherwise
easily become hazaradous.

In the same style, there's usually a 'no_proxy' environment variable as well
that defines a list of hosts that don't need the proxy.

> 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

I could go with this approach.

-- 
      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