AW: AW: AW: Segmentation Fault with SVN Client related to serf

> -----Ursprüngliche Nachricht-----
> Von: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Gesendet: Mittwoch, 7. Januar 2015 14:51
> An: Viret Pierre, PF54
> Cc: users_at_subversion.apache.org
> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
>
> <pierre.viret_at_postfinance.ch> writes:
>
> > You asked for the whole sequence of request, here is the whole tracing
> > of our proxy: I hope this helps. But as already said: the svn client
> > does not crash always but 30% of the times we execute exactly the same
> > ls command.
>
> This is a bit confusing:
>
> 2015-01-06 15:43:24,260 DEBUG ProxyHttpHandler - <====null: HTTP/1.1 200 OK
> 2015-01-06 15:43:24,261 DEBUG ProxyHttpHandler - Do not send null key back
> to client null: HTTP/1.1 200 OK
>
> That's the HTTP status line so why the message about not sending it back to the
> client? I'd expect everything to break if the proxy doesn't send the status line
> back. Is the proxy really blocking the status line?
> It's hard to believe so I think the message must mean something else.
> If you were to use a socat proxy between the client and your main proxy we could
> see exactly what the client is receiving.
>
> I see the client sending 2 OPTIONS requests which is typical for a modern client
> negotiating Subversion's v2 protocol. The first server response contains SVN-Me-
> Resource indicating a modern server that supports v2, but the second response
> does not include it. Why did the server stop supporting v2? Is there some sort of
> load balancer sending requests to multiple servers, or some sort of HTTP caching?
> Almost all the headers are missing from the second OPTIONS repsonse.
>
> The client goes on to send v1 PROPFIND requests to !svn/vcc/default and
> !svn/bln, so the second OPTIONS response appears to have prevented the
> v2 protocol being used.
>
> It's still not clear to me why the client fails but it may be hard to reproduce outside
> of your environment given the strange behaviour of the server.
>
>

I have found following in our apache config for the subversion server:

<VirtualHost @@midw.node.listen.https.address@@:@@midw.node.listen.https.port@@>
    ServerName @@httpd.ip.name1@@

    SSLEngine ON

    BrowserMatch ".*MSIE [2-5]\..*" \
        nokeepalive ssl-unclean-shutdown \
        downgrade-1.0 force-response-1.0

###replace:expand_vhhttps###
</VirtualHost>

This could explain the nokeepalive and the downgrade to 1.0? I'm not sure why this is here, I will check it with our Apache expert.

Remarque concernant la sécurité:
Ce courriel provenant de PostFinance est signé. Vous trouverez d'autres informations à ce sujet sous:
https://www.postfinance.ch/e-signature.
Ne divulguez jamais vos éléments de sécurité à des tiers.