> -----Ursprüngliche Nachricht----- > Von: Philip Martin [mailto:philip.mar...@wandisco.com] > Gesendet: Mittwoch, 7. Januar 2015 14:51 > An: Viret Pierre, PF54 > Cc: users@subversion.apache.org > Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf > > <pierre.vi...@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.
smime.p7s
Description: S/MIME Cryptographic Signature
