proxy support (was Re: New Tarball with connections fixed.)

[Daniel Stenberg <da...@haxx.se>]

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

Re: proxy support

[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

Re: proxy support

["Jonathan M. Manning" <jm...@alisa-jon.net>]

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 (was Re: New Tarball with connections fixed.)

[Mark Benedetto King <bk...@answerfriend.com>]

On Thu, Nov 01, 2001 at 08:08:55AM +0100, Daniel Stenberg 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.

Right.  lynx and wget both use "http_proxy".   Yes, it should be set
by the client code, instead of hard-coded in libsvn_ra_dav, which is
where I put it (I was trying to minimize the scope of the change).


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

They could, in theory, require other things (kerberos tickets, etc).

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

I can throw another twist in:  when I'm at work, I'm behind a proxy, so I want
one.  When I'm not at work, I'm behind a NAT gateway, so I don't.   Of course,
I could solve this by switching .svnrc files based on where I am, but it makes
my life easier to simply set an environment variable when I'm at work.

I'm not so happy with command-line approaches; it's a PITA to type a proxy
address on each svn invocation.


--ben



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org