subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject AW: AW: AW: Segmentation Fault with SVN Client related to serf
Date Fri, 09 Jan 2015 09:46:27 GMT

> -----Ursprüngliche Nachricht-----
> Von: Philip Martin []
> Gesendet: Mittwoch, 7. Januar 2015 14:51
> An: Viret Pierre, PF54
> Cc:
> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
> <> 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


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:
Ne divulguez jamais vos éléments de sécurité à des tiers.
View raw message