On 09.01.2015 10:46, pierre.vi...@postfinance.ch wrote: > >> -----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.
There's a bit of confusion here: This directive forces the server to downgrade to HTTP/1.0 for older versions of Internet Explorer. A normal Subversion client's User Agent string won't match that regular expression. Also, we're talking about Subversion's HTTP-based protocol, which there are two versions of, and they're only marginally related to the underlying HTTP version. -- Brane
