subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf
Date Fri, 09 Jan 2015 10:13:05 GMT
On 09.01.2015 10:46, wrote:
>> -----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
>> 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

View raw message