Return-Path: 
 <users-return-17184-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org>
X-Original-To: apmail-subversion-users-archive@minotaur.apache.org
Delivered-To: apmail-subversion-users-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id D8072EFDC
	for <apmail-subversion-users-archive@minotaur.apache.org>;
 Thu,  7 Feb 2013 14:18:47 +0000 (UTC)
Received: (qmail 71315 invoked by uid 500); 7 Feb 2013 14:18:47 -0000
Delivered-To: apmail-subversion-users-archive@subversion.apache.org
Received: (qmail 71267 invoked by uid 500); 7 Feb 2013 14:18:47 -0000
Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@subversion.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@subversion.apache.org>
List-Post: <mailto:users@subversion.apache.org>
List-Id: <users.subversion.apache.org>
Delivered-To: mailing list users@subversion.apache.org
Received: (qmail 71254 invoked by uid 99); 7 Feb 2013 14:18:46 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Feb 2013 14:18:46 +0000
X-ASF-Spam-Status: No, hits=-1.6 required=5.0
	tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [207.126.148.90] (HELO eu3sys201aog102.obsmtp.com)
 (207.126.148.90)
    by apache.org (qpsmtpd/0.29) with SMTP; Thu, 07 Feb 2013 14:18:38 +0000
Received: from mail.mos-tangram.com ([217.193.163.4]) (using TLSv1) by
 eu3sys201aob102.postini.com ([207.126.154.11]) with SMTP
	ID DSNKURO3qUwhiywxknM3nTsA3oevuu8q1fCP@postini.com;
 Thu, 07 Feb 2013 14:18:18 UTC
Received: from BOSEXCH004.mos-tangram.local ([::1]) by
 BOSEXCH005.mos-tangram.local ([::1]) with mapi id 14.02.0247.003; Thu, 7 Feb
 2013 15:18:16 +0100
From: Michael Zender <michael.zender@mos-tangram.com>
To: "'users@subversion.apache.org'" <users@subversion.apache.org>
Subject: Could not read chunk size: connection was closed by server on
 Windows 7
Thread-Topic: Could not read chunk size: connection was closed by server on
 Windows 7
Thread-Index: Ac4FPfeujIB1LHUrQMKqLVd9faJQsw==
Date: Thu, 7 Feb 2013 14:18:15 +0000
Message-ID: 
 <DC39CC3AE9AC8F46997BE6878E4963236BC71427@BOSEXCH004.mos-tangram.local>
Accept-Language: de-CH, en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.41.147]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Checked: Checked by ClamAV on apache.org

Hello everyone,

a couple of days ago, I configured our apache webserver to serve our
internal subversion repositories over plain old http. Before that, the
repositories have only been accessible using https. Everything seemed to
work pretty smoothly but after a couple of hours I had more and more
complaints about problems that occurred while working (svn co, svn ls
-v) with directories containing a large number of files (> 3000).

The error message reported was something like the following:
svn ls http://<servername>/<repourl>/<repopath> -v
svn: PROPFIND of '/<repourl>/!svn/bc/<rev>/<repopath>': Could not read
chunk size: connection was closed by server (http://<servername>)

svn co http://<servername>/<repourl>/<repopath>
svn: REPORT of '/<repourl>/!svn/vcc/default': Could not read chunk size:
connection was closed by server (http://<servername>)
An interesting fact about the checkout is, that the working copy has
been created and so far I've had no problem with it.

I started investigating and was able to reproduce the problem first in
the live environment before replicating it on a completely different
server. The specs are:
OS: Debian GNU/Linux 6.0.6 (squeeze)
Webserver: Apache/2.2.16
Subversion: svn, version 1.6.12 (r955767)

I created a test repository with the following script
svnadmin create project_Test
chown www-data:www-data project_Test -R
svn co file:///var/lib/subversion/project_Test wc_project_Test
cd wc_project_Test
mkdir src
for i in {1..1000}
do
        head -c 10K < /dev/urandom > src/testfile$i.dat
done
svn add src
svn ci -m "test commit"

The script creates a new repository "project_Test" containing a src
directory with 1000 10kB files with random content.

And made it available in via apache using the following VirtualHost
configuration:

<VirtualHost *:80>
        ServerName svntest

        <Location /svn>
                DAV svn
                SVNParentPath /var/lib/subversion/
                SVNListParentPath On
        </Location>
</VirtualHost>

With this setup I was able to reproduce the checkout problem. I
increased the number of files in the directory to up to 4500 but as of
now, I've not been able to reproduce the svn ls -v problem.

I did a lot of analysis and my conclusion is, that the problems only
occur on Windows 7 using any client software we have in use (Eclipse
integrated client, TortoiseSVN, sv command line client). On WindowsXP
as well as on Linux, there's no problem at all working with the
repository using http communication. When I execute the svn co operation
on a debian system installed on a VirtualBox VM hosted on my Windows 7
I have the same problem as directly on the Windows 7 client.

I know that there are a lot of emails on this list describing the same
error message and I spent quite some time to scan through them and to
follow the links but so far none of them contained a solution for my
particular problem.

I'll also gladly provide any further information that you find useful to
further analyze the problem.

Thank you very much in advance for your help!

Michael