Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf

<pierre.viret_at_postfinance.ch> writes:

> The status line is not blocked. The debugging message means that we
> have got an header with a null key and with the status line as value:
> in this case the header is not added to the request sent back to the
> client. This seems to be common that some HTTP Implementations return
> such a null key header in the list of headers of a request.

I've never seen Apache send a second status line. Perhaps the message
about null key applies to this mysterious line in the trace:

ch.nevis.session.secroles: auth.strong,idma_Benutzer,infplat_user,esclienttest_r
oleBC,esclienttest_roleA,esclienttest_roleB,depo_Admin,itam_Leser,itam_Administr
ator,itsms_asset_viewer,itsms_svc_req_usr,testsaml_admin,global.allow,acc.idma,a
cc.infplat,acc.esclienttest,acc.depo,acc.itam,acc.itsms,acc.testsaml

I see that every response also has:

  Connection: close

This looks as if you do not have KeepAlive enabled on the server, or
perhaps the proxy does not support pipelining. That is going to result
in poor performance for clients that use serf.

All the above is probably irrelevant to the problem.

I've converted your trace into a Python script to implement a server
that behaves like yours. The first, larger, OPTIONS response is a
typical response from a server that supports Subversion's v2 protocol.
The second, smaller, OPTIONS response is the client probing to see if
chunked transfer encoding is upported. All the subsequent PROPFINDS are
v1 protocol and this is where it gets tricky.

Using a standard 1.8 client against this dummy server gives:

$ svn ls http://127.0.0.1:7777/svn/t_sponis_testrepo
svn: E175009: XML Parsing failed: Unexpected root element 'multistatus'

That's because the client sends v2 requests and the v1 responses do not
match. Now I have a debug client and I can force v1 using

$ SVN_I_LIKE_LATENCY_SO_IGNORE_HTTPV2=yes svn ls http://127.0.0.1:7777/svn/t_sponis_testrepo
branches/
tags/
trunk/

Your client will not have the debug code to do that. How is your client
switching to the v1 protocol? Either your proxy is not forwarding the
SVN-Me-Resource header or your client is patched to ignore v2, which
ever it is your environment is non-standard. How does your client
respond when run against this dummy server? (You must restart the dummy
server after a client fail so that responses match the requests.)

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*