Proxy settings in SVN

87 views
Skip to first unread message

Vaux, John

unread,
Sep 12, 2014, 1:09:24 AM9/12/14
to us...@subversion.apache.org

Hello all,

                It’s my first time posting to this list and I am not subscribed so please CC me on any replies.

 

                I’m having difficulty with the proxy settings in Windows version of svn (I’m using the WANdisco compiled version).  It seems as though no matter what I put in the appdata\roaming\subversion\servers file the settings are ignored and the svn is defaulting to the windows control panel settings.  This would be fine but we utilize a proxy.pac autoconfigure and require proxy authentication.  Between those two settings for whatever reason svn seems to be unable to deal with the proxy’s request for authentication.  I’ve tcpdumped the connection information from the proxy itself and it looks like svn just isn’t answering.

 

The basic gist of the stream goes like this:

Source                  Dest                       Protocol               Length                  Message

clientIP                 proxyIP                HTTP                      121                         CONNECT www.svnrepository.tld:443 HTTP/1.1

proxyIP                clientIP                 HTTP                      236                         HTTP/1.1 407 authenticationrequired  (text/html)

clientIP                 proxyIP                HTTP                      217                         CONNECT www.svnrepository.tld:443 HTTP/1.1 , NTLMSSP_NEGOTIATE

proxyIP                clientIP                 HTTP                      252                         HTTP/1.1 407 authenticationrequired , NTLMSSP_CHALLENGE (text/html)

 

And then silence.  The app correctly interprets the first 407 and tries connecting again but this time with an NTLMSSP_NEGOTIATE but when the proxy comes back with a CHALLENGE svn never responds with credentials.  I worked with my proxy vendor and we tried to find ways around it but short of turning off authentication they are chalking it up to a bug in the HTTP client implementation.  Any help would be much appreciated.

 

John Vaux

Enterprise Infrastructure Architect

Information Technology Services

Phoenix Children's Hospital

Office: 602-933-2592

Mobile: 602-501-3052

jv...@phoenixchildrens.com

 


This transmission, including any attachments, is for the sole use of the intended recipient (s) and may contain information that is confidential, proprietary, legally privileged, or otherwise protected by law from disclosure. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, or the person responsible for delivering this to an addressee, you should notify the sender immediately by telephone or by reply e-mail, and destroy all copies of the original message.

Johan Corveleyn

unread,
Sep 12, 2014, 5:10:20 AM9/12/14
to Vaux, John, us...@subversion.apache.org
Hello John,

It's indeed possible that this is related to a problem in de http
client implementation inside svn (i.e. the serf library which takes
care of the http communication). Can you show us the output of 'svn
--version', so we know the exact version of svn (and version of serf
that is included)?

If it's not the latest version (1.8.10 if I'm not mistaken), you might
want to try upgrading your client and see if that helps already. There
were some subtle http communication bugs fixed in recent 1.8.x
releases.

Cheers,
--
Johan

Vaux, John

unread,
Sep 12, 2014, 10:52:08 AM9/12/14
to Johan Corveleyn, us...@subversion.apache.org
Johan,
Absolutely, I should have included that in my original email. I've downloaded the latest available specifically for my testing environment so svn --version does indeed come back with 1.8.10.

John Vaux
Enterprise Infrastructure Architect
Information Technology Services
Phoenix Children's Hospital
Office: 602-933-2592
Mobile: 602-501-3052
jv...@phoenixchildrens.com


Johan Corveleyn

unread,
Sep 15, 2014, 3:50:42 AM9/15/14
to Vaux, John, us...@subversion.apache.org
[ This list prefers bottom- or inline-posting, so please put your
reply inline or at the bottom, thanks. More below ...]
On Fri, Sep 12, 2014 at 4:51 PM, Vaux, John <JV...@phoenixchildrens.com> wrote:
> Johan,
> Absolutely, I should have included that in my original email. I've downloaded the latest available specifically for my testing environment so svn --version does indeed come back with 1.8.10.
>

Mmm, that's the most recent release ...

For completeness, can you copy-paste the full output of "svn
--version"? That includes the version number of the serf library
that's included.

I'm not an expert on serf's internals myself, but I've done a quick
search in the mailinglist archives on "negotiate", and a couple of
threads have come up:

http://svn.haxx.se/dev/archive-2013-06/0413.shtml
http://svn.haxx.se/dev/archive-2014-08/0222.shtml

There is also this recent commit, related to the http-pipelining that
was discussed in that latest thread (reverting the option, because
that particular issue was fixed in serf 1.4):
http://svn.apache.org/viewvc?view=revision&revision=r1621180

I'm not sure if any of this is related to the issue you are seeing,
but perhaps you can already read throught those threads to see if it
matches your problem. It's also perfectly possible that you're seeing
a new issue.

If you need a workaround, a product like cntlm [1] might be of some help.

[1] http://cntlm.sourceforge.net/

--
Johan

Lieven Govaerts

unread,
Sep 15, 2014, 4:37:49 AM9/15/14
to Vaux, John, us...@subversion.apache.org
Hi,

On Thu, Sep 11, 2014 at 11:03 PM, Vaux, John <JV...@phoenixchildrens.com> wrote:
What do you mean with silence? Does the svn client hang? Does it exit
with an error?

> The app correctly interprets the first 407 and tries
> connecting again but this time with an NTLMSSP_NEGOTIATE but when the proxy
> comes back with a CHALLENGE svn never responds with credentials. I worked
> with my proxy vendor and we tried to find ways around it but short of
> turning off authentication they are chalking it up to a bug in the HTTP
> client implementation. Any help would be much appreciated.
>

We'll probably need serf log output to find out in detail what's
happening. Alas in serf 1.3.x logging can only be enabled at
compile-time, so you'll need to either build serf + svn manually, or
maybe one of the Windows devs (Ivan? Bert?) can provide you with a
Windows 1.8 client with serf logging enabled?

Lieven

Vaux, John

unread,
Sep 15, 2014, 12:36:29 PM9/15/14
to Johan Corveleyn, us...@subversion.apache.org
Full output of SVN as requested:
svn, version 1.8.10 (r1615264)
compiled Aug 8 2014, 12:14:52 on x86/x86_64-microsoft-windows6.1.7601
Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- using serf 1.3.4
- handles 'http' scheme
- handles 'https' scheme

-John

Vaux, John

unread,
Sep 15, 2014, 12:52:44 PM9/15/14
to Lieven Govaerts, us...@subversion.apache.org
> -----Original Message-----
> From: lieven....@gmail.com [mailto:lieven....@gmail.com] On
> Behalf Of Lieven Govaerts
> Sent: Monday, September 15, 2014 1:37 AM
> To: Vaux, John
> Cc: us...@subversion.apache.org
> Subject: Re: Proxy settings in SVN
>
Silence was in reference to the TCP stream. I would expect after the negotiate to receive authentication information from the client but instead I get nothing.

On the client itself it pretty quickly throws an error:
svn: E120190: Unable to connect to a repository at URL 'https://repositoryURL'
svn: E120190: Error running context: An error occurred during authentication

>
> > The app correctly interprets the first 407 and tries connecting
> again
> > but this time with an NTLMSSP_NEGOTIATE but when the proxy comes back
> > with a CHALLENGE svn never responds with credentials. I worked with
> > my proxy vendor and we tried to find ways around it but short of
> > turning off authentication they are chalking it up to a bug in the
> > HTTP client implementation. Any help would be much appreciated.
> >
>
> We'll probably need serf log output to find out in detail what's
> happening. Alas in serf 1.3.x logging can only be enabled at compile-
> time, so you'll need to either build serf + svn manually, or maybe one
> of the Windows devs (Ivan? Bert?) can provide you with a Windows 1.8
> client with serf logging enabled?
>
> Lieven
>

If someone has a windows compiled version with the option enabled that would be terrific.

-John
Reply all
Reply to author
Forward
0 new messages