PATCH: using the env-var http_proxy

[Joerg Beyer <jo...@webde-ag.de>]

    Hi,

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.

hope this helps
Joerg

--- subversion/libsvn_ra_dav/session.c_orig Fri Dec 7 20:02:52 2001
+++ subversion/libsvn_ra_dav/session.c Fri Dec 7 20:17:24 2001
@@ -103,6 +103,7 @@ svn_ra_dav__open (void **session_baton,
ne_session *sess, *sess2;
struct uri uri = { 0 };
svn_ra_session_t *ras;
+ char* proxy = 0;

/* Sanity check the URI */
if (uri_parse(repository, &uri, NULL)
@@ -123,6 +124,28 @@ svn_ra_dav__open (void **session_baton,
/* Create two neon session objects, and set their properties... */
sess = ne_session_create();
sess2 = ne_session_create();
+
+ proxy = getenv("http_proxy");
+ if (proxy)
+ {
+ proxy = strdup(proxy);
+ // if the env-var named http_proxy is set to something like
+ // "http://myproxy.mydomain.com:3128" then we could use it.
+ if (strncmp(proxy,"http://",7) == 0)
+ {
+ char* host = &proxy[7];
+ char* colon = index(host,':');
+ if (colon)
+ {
+ int proxy_port = atoi(&colon[1]);
+ *colon = 0; // split of the hostname part
+ //fprintf(stderr,"using a proxy (%s, %d)\n",host,proxy_port);
+ ne_session_proxy(sess , host, proxy_port);
+ ne_session_proxy(sess2, host, proxy_port);
+ }
+ }
+ free(proxy);
+ }

#if 0
/* #### enable this block for debugging output on stderr. */


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

RE: Re: PATCH: using the env-var http_proxy

[Bill Tutt <ra...@lyra.org>]

> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> 
> Perhaps the whole question of proxy detection belongs in APR?
> 

Well, by default I'd think it should all be neon's problem, because it
is our http connection library.  Of course, we all know how handy having
neon use APR would be. :) However, sticking the code into APR is
certainly likely to get it more exposure, which isn't the worst thing on
the planet.

> I know that sounds odd, but it seems like proxy setting is highly
> platform- and tradition-specific, which is something APR should deal
> with, not Subversion nor probably Neon.
> 
> Should there just be an apr_get_http_proxy() interface?
> 

In a perfect world, neon would auto-magically take proxy info into
account and just make it happen.

(Just to make life annoying, IE proxy info even gives you exclusion
patterns to the proxy info, so you have to decide when is appropriate to
actually use the proxy server, etc...)

This (proxy exclusions) makes sense for SVN anyway. You have to support
accessing live internet repositories outside the proxy, and
simultaneously not make life too annoying for the folks who need to
access intranet repositories at the same time.

The easiest way in the short run is to just stick some proxy config info
into .svnrc. 

e.g.:
Default proxy config settings
Per Repository overrides for config settings
Etc...

NTLM authenticating proxies:
If you're using Microsoft's proxy server this isn't an issue on Win32
boxes, because they'll have the Winsock proxy client installed.

Bill


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

Re: PATCH: using the env-var http_proxy

[Karl Fogel <kf...@newton.ch.collab.net>]

"Bill Tutt" <ra...@lyra.org> writes:
> Just as an FYI, no matter where the proxy detection code goes, there
> should be an issue entered to retrieve the IE proxy information via the
> appropriate API. Win32 folks shouldn't have to set environment
> variables. :)

Perhaps the whole question of proxy detection belongs in APR?  

I know that sounds odd, but it seems like proxy setting is highly
platform- and tradition-specific, which is something APR should deal
with, not Subversion nor probably Neon.

Should there just be an apr_get_http_proxy() interface?

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

RE: Re: PATCH: using the env-var http_proxy

[Bill Tutt <ra...@lyra.org>]

Just as an FYI, no matter where the proxy detection code goes, there
should be an issue entered to retrieve the IE proxy information via the
appropriate API. Win32 folks shouldn't have to set environment
variables. :)

Bill



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

Re: PATCH: using the env-var http_proxy

[Karl Fogel <kf...@newton.ch.collab.net>]

cmpilato@collab.net writes:
> If you want the command-line client to read the HTTP_PROXY environment
> variable, that's fine.  Just stick the parse results in the above
> optstate_t fields, and make sure that passing the values as
> command-line options always overrides the getenv() findings.

Note that the client also should not be using getenv() directly --
probably that belongs in the portability layer, APR.  Don't know if
APR has a getenv()-like feature, but it shouldn't be hard to add if
not.

-K

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

Re: PATCH: using the env-var http_proxy

[cm...@collab.net]

Forgot to add:

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

If you want the command-line client to read the HTTP_PROXY environment
variable, that's fine.  Just stick the parse results in the above
optstate_t fields, and make sure that passing the values as
command-line options always overrides the getenv() findings.

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


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

Re: PATCH: using the env-var http_proxy

[Greg Stein <gs...@lyra.org>]

On Fri, Dec 21, 2001 at 12:45:37PM -0600, cmpilato@collab.net wrote:
>...
> We've been around this topic of proxies a couple of time before.  Here

Yah... there is an open issue on it, which is marked post-1.0 (by Karl, I
believe?). I think it should be fixed for 1.0, really.

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

Agreed. I like Karl's apr_get_http_proxy() idea.

>...
>   - two (2) additions to the svn_cl__optstate_t structure in the
>     command-line client called `proxy_machine' and `proxy_port'.

'proxy_host' and 'proxy_port'

But then you also forgot 'proxy_user' and 'proxy_password'. Of course, you
might also be authenticating via NTLM with your proxy, but we'll leave that
nastiness to Neon :-). We *do* need to give it four pieces of information,
though: user, password, host, port.

>...
> And you know what?  I probably could have written the code in less
> time than it took to write this mail.

And because you lacked the user/pass, it would not have been right :-)

Personally, I don't feel a working copy is going to (necessarily) be
portable. I'm not sure what all is going to be in there which will be
non-portable, but newline handling is one. user/pass might not be desirable,
but it would certainly not create portability issues.

Regarding implementation: we would need to pass proxy host/port into RA (or
more specifically: ra_dav), and then have a proxy_userpass authenticator.

Note that proxy host/port can come from APR, and it can also be supplied by
a .svnrc file (or an /etc/svn.rc type thing).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

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

Re: PATCH: using the env-var http_proxy

[cm...@collab.net]

Joerg Beyer <jo...@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