subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Zender <>
Subject AW: Could not read chunk size: connection was closed by server on Windows 7
Date Wed, 13 Feb 2013 13:46:38 GMT
> -----Urspr√ľngliche Nachricht-----
> Von: Mark Phippard []
> Gesendet: Freitag, 8. Februar 2013 18:34
> An: Michael Zender
> Cc:
> Betreff: Re: Could not read chunk size: connection was closed by
> server on Windows 7
> On Fri, Feb 8, 2013 at 10:28 AM, Michael Zender
> <> wrote:
> > I finally solved my problem and wanted to share my solution with
> you.
> Thanks for letting us know.
> > It turned out, that Kaspersky Endpoint Security 8 and its Web-Anti-
> Virus
> > feature in particular were causing this problem to show up. We
> solved it
> > by defining a rule that excludes our subversion servers from the
> > Web-Anti-Virus service. The Windows XP still had Kaspersky 6
> installed
> > which does not have the Web-Anti-Virus feature.
> I was thinking on this overnight, and believe it or not I was going to
> propose you look in this general direction.
> > I still don't know what exactly the problem is because in my
> opinion,
> > the anti virus software should act in a completely transparent
> manner
> > but anyways, it's working now, so I don't bother any more!
> If you look at the FAQ and remove some of the specifics, more
> generally what it is saying is that while the client is doing some
> work the connection to the server is closed in a manner that the
> client is not expecting it.  So the error manifests to the client as a
> chunk delimiter error when the data it is reading disappears.  The FAQ
> describes one scenario that caused this, the server ending the
> connection.
> These Windows anti-virus solutions operate at a low level so they can
> intercept and monitor your TCP/IP traffic.  I would guess that either
> Subversion's pattern of HTTP requests looked unusual or perhaps even
> the content in one of your files.  My guess is that when these tools
> sense a problem they do not try to be graceful about it.  It probably
> just kills the connection.  After all if it were a virus or trojan
> horse on your computer it does not want to make it easier for the
> malicious code to recover.  So most likely when it senses a problem it
> closed the connection and that manifested itself the same as the
> server timeout.
> One thing that might be helpful is to look into what kind of logging
> the tool provides. It would be nice if they log some forensic data
> about what caused them to do this.  Maybe that information can go back
> to Kapersky to make the tool not do this.  Or maybe it is just a bug
> in their tool where they cannot handle all of the requests and how
> fast they are being made.  I suspect a SVN client drives HTTP traffic
> a lot differently than a typical web browser loading a page does.
> > Thanks again to Mark for his reply, it definitely made me
> investigate in
> > the right direction.
> You are welcome and thanks for sharing the information back.  Do you
> have any suggestions on how this FAQ could be improved to add this
> information?
> --
> Thanks
> Mark Phippard

Hi Mark,

thank you for your detailed explanation.

You are right, that anti-virus software would just close a suspicious
connection and not care about the aftermath. I did not even remotely
think of the possibility that maybe the anti-virus software is actually
detecting a virus :)!

So I checked with our infrastructure department but the log files for my
machine don't report anything in that direction. I also don't think that
this is the case because I also observed the problem with an artificial
repository containing only generated files with random content.

Regarding the FAQ, I think you could add to the section that you
mentioned earlier ( that
the problem may also originate not only from the server- but also from
the client side and explicitly mention anti-virus software as a possible
source of the problem.

Thanks again!

Best regards


View raw message