[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Http proxy patch [Was: Re: blah... blah...

From: Dale Thatcher <subversion_at_dalethatcher.com>
Date: 2001-09-16 16:06:10 CEST

Here are the changes I propose to make:

1) Add a proxy callback that will be called with the repos URL. It returns a
proxy host and port or null. This would allow clients to make more
complicated decisions on which proxy to use. Therefore allowing them to
behave in the same way as web browsers with a proxy for most and a list of
exceptions. The client would be responsible for choosing the appropriate
proxy for each situation.

2) Make a default callback that returns NULL.

3) Add callbacks for proxy username and password.

Comments?

thanks,

- Dale Thatcher

On Sat, Sep 15, 2001 at 12:07:30AM +0200, Branko Cibej wrote:
> C. Scott Ananian wrote:
>
> >On Thu, 13 Sep 2001, Branko Cibej wrote:
> >
> >>And so do the getenvs. Use a comand-line option instead.
> >>
> >>-1 (veto) on having Subversion's behaviour depend on environment variables.
> >>
> >
> >presumably the proxy option will either be stored in the working copy
> >
> Hm. Sometimes you need different proxies to get to different servers.
> Using an env var would be bad in such (probably rare) cases.
>
> > or
> >settable in a .svnrc file somewhere? I don't think repeatedly typing
> >'--http-proxy=longurlhere' on the command-line is going to win us many
> >friends. The vote for the http_proxy environment variable is that *this
> >is how most applications behave* -- the perl HTTP modules, wget, dselect,
> >etc -- and the system administrator can set this in the user's default
> >environment to have things 'just work' for the users. Administering a
> >proxy is made *much much much* more difficult if every user must manually
> >set up every application by themselves. Surely this isn't the intent?
> >
> Of course not. There will be a global /etc/svn.conf file, and a ~/.svnrc
> file, where this option can be defaulted. In the meantime, shell aliases
> (perhaps in global config files) are a good alternative.
>
>
> Relying on environment variables creates a maintenance nightmare,
> especially since not all variables are "standard" on all systems. We
> can't avoid honoring truly standard variables like LANG and LC_*
> (although we do our best with --locale), but IMO should avoid others.
> Putting options in a .rc file at least doesn't pollute the env space for
> other apps.
>
> Then again, maybe I'm paranoid.
>
>
> <rant>Why can't people use transparent proxies?</rant>
>
> --
> Brane Cibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
>
>
>
>
> ---------------------------------------------------------------------
> 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:41 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.