subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vaux, John" <JV...@phoenixchildrens.com>
Subject RE: Proxy settings in SVN
Date Mon, 15 Sep 2014 16:35:49 GMT
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: Monday, September 15, 2014 12:50 AM
> To: Vaux, John
> Cc: users@subversion.apache.org
> Subject: Re: Proxy settings in SVN
> 
> [ This list prefers bottom- or inline-posting, so please put your reply
> inline or at the bottom, thanks. More below ...]
> 
> > -----Original Message-----
> > From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> > Sent: Friday, September 12, 2014 2:10 AM
> > To: Vaux, John
> > Cc: users@subversion.apache.org
> > Subject: Re: Proxy settings in SVN
> >
> > On Thu, Sep 11, 2014 at 11:03 PM, Vaux, John
> <JVaux@phoenixchildrens.com> wrote:
> >> 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.
> >>
> >
> > 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
> >
> 
> On Fri, Sep 12, 2014 at 4:51 PM, Vaux, John
> <JVaux@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

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


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.
Mime
View raw message