[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 09 Jan 2015 11:18:37 +0000

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

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2015-01-09 12:19:08 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.