Re: PATCH: using the env-var http_proxy

Joerg Beyer <job@webde-ag.de> writes:

> last night I built my own svn. Since I have an application level
> gateway between me and the internet (nice name for a squid :-), I
> need svn to respect the http_proxy environment variable. The patch
> is easy, but only helps in the case where you use http, so it don't
> helps if you use https.
>
> In case anybody else could use it I send the patch.
>
> Feel free to use it or correct me if you dont like anything about it.

Joerg: this mail is not aimed specifically at you. Just using your
mail as a springboard for the headfirst dive into the empty pool I'm
about to take. :-) Oh, I guess it is, however, a rebuke of your
patch, but don't take it personally.

--
We've been around this topic of proxies a couple of time before.  Here
are my thoughts on the matter.  I seem to recall some complaints in
the past about using the HTTP_PROXY environment variable.  I
personally don't give a rip about how you tell your Subversion client
that you have a proxy to deal with, environment variable or not.
I do *not*, however, want to see "getenv" inside our libraries.  This
kind of thing is completely client-specific, and therefore should be
ascertained by the client itself, and delivered to the appropriate
libraries for use via an appropriate public API.
I was thinking this should be treated as just another authentication
item, passed on the commandline as --proxy-machine and --proxy-port,
and stored in the auth directory with the username and password and
such.  The problem with this is that right now, you can tar up a
Subversion working copy and move it to another location, another
machine, another planet if you wish, untar it and it will work for
you.  This property won't hold true if the working copy itself caches
proxy information (the proxy may not be the same, or in use at all,
from a different location).
So, perhaps this is just the kind of thing that the client must
provide to the underlying libraries each time the client is invoked.
I'm totally cool with that, in fact, it feels More Correct to me the
more I think about it.
So, what I'd like to see as far as proxy-use patches goes is a
beautiful implementation of something like:
  - two (2) additions to the svn_cl__optstate_t structure in the
    command-line client called `proxy_machine' and `proxy_port'.
  - svn_cl__make_auth_baton() gets that information via it's optstate
    parameters, and stores the values in the auth baton.
  - the auth caching code uses, but does NOT cache those two values
    (but of course, continuing to cache usernames and passwords and
    whatever_else).
And you know what?  I probably could have written the code in less
time than it took to write this mail.
Praise and criticism can be directed at cmpilato@collab.net, care of
this mailing list.  I might not be around to defend myself until early
January, though.
Love,
C-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org