W dniu 01.08.2016 o 10:19, Lieven Govaerts pisze:
>
>
> Op donderdag 28 juli 2016 heeft Stefan Sperling <stsp_at_elego.de <mailto:stsp_at_elego.de>> het volgende geschreven:
>
> On Wed, Jul 27, 2016 at 06:56:46PM +0200, Krzysztof Smiechowicz wrote:
> > Hi All,
> >
> > We are having problems accessing our svn server via https with client newer
> > than 1.7.22 - 1.8.16 and 1.9.3 to be specific. The problem is that the newer
> > clients come up with authentication request during svn checkout which after
> > entering correct password fails. The authentication comes at random moments
> > during checkout. The difference we could spot so far was that 1.7.22 was
> > using ra_neon and newer clients are using ra_serf for HTTPS.
>
> My guess is that you need to increase the MaxKeepAliveRequests setting
> in httpd.conf on the SVN server.
>
> Once the MaxKeepAliveRequests limit is reached the server closes the
> connection so the client opens a new one and authenticates again.
>
> Serf-based clients send a lot more requests than Neon-based clients.
> It seems the Neon-based clients do not trigger the limit in your
> situations, while Serf-based clients do.
>
>
> Ra_serf first opens one connection during checkout, and then opens more connections to get the data when needed. My
> guess is that the authn request comes when opening those 2nd, 3rd connections, not when the server initiates a
> connection close.
>
> The fact that serf sends more requests and therefore uses multiple connections should not make svn ask for credentials
> multiple times, they are cached in memory for Basic and Digest authentication. So there seems to be something wrong.
>
> As a workaround, it's possible to make svn use one single connection for checkout, update and merge by
> setting SVNAllowBulkUpdates to Prefer in the apache configuration file.
> See:
> https://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.perf.bulk-updates
>
Thank you for the workaround. This solves the problem for us!
Best regards,
Krzysztof
Received on 2016-08-01 21:51:51 CEST