On 09.01.2015 10:46, pierre.viret_at_postfinance.ch wrote:
>
>> -----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.
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
Received on 2015-01-09 11:14:27 CET