AW: AW: 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: Freitag, 9. Januar 2015 12:19
> An: Viret Pierre, PF54
> Cc: users_at_subversion.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: Segmentation Fault with SVN Client related to
> serf
>
> <pierre.viret_at_postfinance.ch> writes:
>
> > Yes you are right, I have not looked at the wireshark output good
> > enough! Unfortunately I cannot change it in our HttpProxy: this
> > change of the case of the header keys is performed by the underlying
> > HTTP Layer in java and not by our own code. I think the reason for
> > this is that the HTTP specification states that the header-keys are
> > case-insensitive (see f.i.
> > http://stackoverflow.com/questions/5258977/are-http-headers-case-sensitive).
>
> It's fixed on trunk and proposed for the next release.
>
> > Maybe if this bug is fixed in the svn client then the segmentation
> > fault would be solved? There might be another header field which is
> > not managed correctly because of case-sensitiveness?
>
> I noticed that your proxy is changing the status line by dropping the
> reason-phrase:
>
> HTTP/1.1 207 Multi-Status
>
> to
>
> HTTP/1.1 207
>
> The client is allowed to ignore the reason-phrase but I don't know whether the
> server is allowed to omit it. A strict reading of the RFC may require at least a
> space after the 207. However, this is not the cause of the crash, at least on my
> machine.
>
> I can't reproduce the crash. I see the trace has "Connection: close" so the problem
> is not probably not extra data between requests. The trace is for a Windows client,
> is it possible to get a trace for the Linux client?
>
> I've converted the trace to a script. Does your Windows client crash when run
> against the dummy server in this script? Does the Linux client crash?

Good news!
I could create a new implementation of the JDK HttpServer which fixes the 207 Status line problem, and I can't reproduce the segmentation fault anymore when the HttpProxy uses this fixed version.
This means that the SVN Client 1.8 now runs successfully the "ls" command if the HttpProxy sends a status line " HTTP/1.1 207 Multi-Status" correctly as stated in the specification. I have performed some tests using TortoiseSVN 1.8 on windows, too, without any error.
We will perform further tests and will inform you in case we get again some error, but I'm optimist and confident that this solves the problem.

Question: do you know when the patch for the header field name case-sensitiveness will be delivered? Is it planned for 1.8.12 SVN client? For me it's important: if we have to wait for a too long time I would try to override the default behavior in Java to ensure that the case of the header field names get not modified and to avoid performance issues.

I think this is important to fix the snv code which causes the segmentation fault in case the status line is missing the space character: this would avoid client crashes with HTTP servers & proxies using the HttpServer implementation included in the Java Virtual Machine. I will post an issue by Java but I have no idea how quickly the problem with the 207 return code would be fix in there.

At this place I would like to thank you very much for your support which is a great help for us!

Here the output of socat on debian when I use the fixed HttpServer version: note the correct status line for code 207! In this case I could not reproduce the segmentation fault, I tried it on windows and on debian.

PROPFIND /svn/t_sponis_testrepo/!svn/bc/16 HTTP/1.1\r
Host: 127.0.0.1:9630\r
User-Agent: SVN/1.8.10 (x86_64-pc-linux-gnu) serf/1.3.7\r
Content-Type: text/xml\r
Accept-Encoding: gzip\r
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth\r
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo\r
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops\r
Depth: 1\r
Transfer-Encoding: chunked\r
\r
71\r
<?xml version="1.0" encoding="utf-8"?><propfind xmlns="DAV:"><prop><resourcetype xmlns="DAV:"/></prop></propfind>\r
0\r
\r
< 2015/01/09 14:40:40.993585 length=474 from=0 to=473
HTTP/1.1 207 Multi-Status\r
Content-type: text/xml; charset="utf-8"\r
Content-length: 1052\r
Ch.nevis.session.secroles: auth.strong,idma_Benutzer,infplat_user,esclienttest_roleBC,esclienttest_roleA,esclienttest_roleB,depo_Admin,itam_Leser,itam_Administrator,itsms_asset_viewer,itsms_svc_req_usr,testsaml_admin,global.allow,acc.idma,acc.infplat,acc.esclienttest,acc.depo,acc.itam,acc.itsms,acc.testsaml\r
Connection: close\r
Server: Apache\r
Date: Fri, 09 Jan 2015 13:40:40 GMT\r
\r
< 2015/01/09 14:40:41.033014 length=1 from=474 to=474
<< 2015/01/09 14:40:41.033281 length=1051 from=475 to=1525
?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:">
<D:response xmlns:lp1="DAV:">
<D:href>/svn/t_sponis_testrepo/!svn/bc/16/</D:href>
<D:propstat>
<D:prop>
<lp1:resourcetype><D:collection/></lp1:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:lp1="DAV:">
<D:href>/svn/t_sponis_testrepo/!svn/bc/16/trunk/</D:href>
<D:propstat>
<D:prop>
<lp1:resourcetype><D:collection/></lp1:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:lp1="DAV:">
<D:href>/svn/t_sponis_testrepo/!svn/bc/16/branches/</D:href>
<D:propstat>
<D:prop>
<lp1:resourcetype><D:collection/></lp1:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response xmlns:lp1="DAV:">
<D:href>/svn/t_sponis_testrepo/!svn/bc/16/tags/</D:href>
<D:propstat>
<D:prop>
<lp1:resourcetype><D:collection/></lp1:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>

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.