You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kyle Echols <su...@kyleechols.com> on 2020/03/09 13:07:41 UTC

Disable Keep Alives and/or Pipelining?

We run through a reverse proxy for SVN access and that proxy has 
KeepAlives disabled, as a result, I've been asked if it's possible to 
disable KeepAlives and/or HTTP Pipelining in the subversion client?

For some background, we are getting SSL errors when trying to checkout / 
update that don't occur going to the server direct (bypassing the proxy) 
and all we see in the reverse proxy (Apache HTTPd under the covers) logs 
are:

     "insecure re-negotiation required, but a pipelined request is 
present; keep alive disabled"

TortoiseSVN returns:

     Error running context: An error occurred during SSL communication

The SVN Server (CollabNET) -

     Reports a broken pipe, with a "HINT: Stop button pressed in 
browser?" type message




Thanks in advance,



Re: Disable Keep Alives and/or Pipelining?

Posted by su...@kyleechols.com.
Thanks Mark, the Proxy supports it but our Proxy team disables it and 
prefers it not be enabled. I have been pushing to get KeepAlives enabled 
and been met with some hesitation, I'm hoping with your answer I'll be 
able to push them to either enable KeepAlives or remove the Reverse 
Proxy requirement for this use case.



On 3/9/20 8:23 AM, Mark Phippard wrote:
> On Mon, Mar 9, 2020 at 9:18 AM Kyle Echols <subversion@kyleechols.com 
> <ma...@kyleechols.com>> wrote:
>
>     We run through a reverse proxy for SVN access and that proxy has
>     KeepAlives disabled, as a result, I've been asked if it's possible
>     to disable KeepAlives and/or HTTP Pipelining in the subversion
>     client?
>
>     For some background, we are getting SSL errors when trying to
>     checkout / update that don't occur going to the server direct
>     (bypassing the proxy) and all we see in the reverse proxy (Apache
>     HTTPd under the covers) logs are:
>
>         "insecure re-negotiation required, but a pipelined request is
>     present; keep alive disabled"
>
>     TortoiseSVN returns:
>
>         Error running context: An error occurred during SSL communication
>
>     The SVN Server (CollabNET) -
>
>         Reports a broken pipe, with a "HINT: Stop button pressed in
>     browser?" type message
>
>
> I have always been under the impression the client and server just 
> negotiate the availability of KeepAlive and manage with our without 
> it. That said, since SVN 1.7 the client has needed KeepAlive enabled 
> for performance to be decent:
>
> http://subversion.apache.org/docs/release-notes/1.7.html#serf
>
> You should get a proxy that supports it
>
> -- 
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/

Re: Disable Keep Alives and/or Pipelining?

Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Mar 9, 2020 at 9:18 AM Kyle Echols <su...@kyleechols.com>
wrote:

> We run through a reverse proxy for SVN access and that proxy has
> KeepAlives disabled, as a result, I've been asked if it's possible to
> disable KeepAlives and/or HTTP Pipelining in the subversion client?
>
> For some background, we are getting SSL errors when trying to checkout /
> update that don't occur going to the server direct (bypassing the proxy)
> and all we see in the reverse proxy (Apache HTTPd under the covers) logs
> are:
>
>     "insecure re-negotiation required, but a pipelined request is present;
> keep alive disabled"
>
> TortoiseSVN returns:
>
>     Error running context: An error occurred during SSL communication
>
> The SVN Server (CollabNET) -
>
>     Reports a broken pipe, with a "HINT: Stop button pressed in browser?"
> type message
>

I have always been under the impression the client and server just
negotiate the availability of KeepAlive and manage with our without it.
That said, since SVN 1.7 the client has needed KeepAlive enabled for
performance to be decent:

http://subversion.apache.org/docs/release-notes/1.7.html#serf

You should get a proxy that supports it

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/