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

> -----Ursprüngliche Nachricht-----
> Von: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Gesendet: Donnerstag, 8. Januar 2015 14:34
> An: Viret Pierre, PF54
> Cc: users_at_subversion.apache.org
> Betreff: Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf
>
[...]
>
> I've never seen Apache send a second status line. Perhaps the message about null
> key applies to this mysterious line in the trace:
>

I suppose that this is some specifical java implementation. I simply get a header with key null and value = status line when I get the list of headers from the HttpsURLConnection from java, and I do not include it in the headers sent back to the client.
See ...

> ch.nevis.session.secroles: auth.strong,idma_Benutzer,infplat_user,esclienttest_r
> oleBC,esclienttest_roleA,esclienttest_roleB,depo_Admin,itam_Leser,itam_Administ
> r
> 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
>

This header is added by the EntryServer and contains the set of roles of the user, but our HttpProxy does not use it.

> 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.
>

I'm not sure what you mean with "pipelining". I would expect that we have KeepAlive enabled but I should check this.

> 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'
>
[...]
> 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.)

I got exactly the same result using your dummy server with my client.

I have captured the http traffic, you will find it in the attachment crash_http_capture.pcap. The debugging output of the HttpProxy is in the attachment crash_http.txt, it differs from the output when using https.
I had to switch from https to http for this. Please note that the crash occurs not exactly at the same time with http, and that we get the segmentation fault each time we run "ls" and not 30% of the time like with https: this could be an interesting point for the analyze.

The subversion server version we use is 1.8.10.

Regards,
Pierre

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.