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

Re: [BUG] 1.6.17 "svn: Bogus date" fatal abort - due to incomplete chunk!?

From: Andreas Mohr <andi_at_lisas.de>
Date: Thu, 10 May 2012 20:57:33 +0200

Hi,

On Thu, May 10, 2012 at 06:32:06PM +0200, Stephen Butler wrote:
> that's an excellent bug report. Unfortunately, TFS SvnBridge isn't an
> Apache Subversion server. It emulates the mod_dav_svn protocol,
> like GitHub does.
>
> http://svn.haxx.se/dev/archive-2012-02/0244.shtml

Hohumm. No nicer way to say "You're On Your Own, Get Lost." :-)

> You'll have to contact the TFS SvnBridge developers.

That would be... me (for all intents and purposes). Argh.
I'll keep a strong mental note (engraved in stone)
to firmly keep away from any kind of Microsoft "infrastructure" / "ecosystem"
in future.

Anyway, more details:
That obviously seems to be a problem with parsing/transmission of
HTTP Chunked Transfers
(and BTW another abort also happened with a "SVN: Malformed XML" error
on another svn operation).
[BTW Google shows 167000 results for "malformed XML subversion",
which might be a tad much to believe them to all be
*actual* payload corruption incidents only]

So far I cannot identify a problem on the SvnBridge side here
(which in itself is astonishing!):
it's configuring response objects to have them
implicitly (internally) do chunked encoding:
response.SendChunked = true;
and it's also making sure to have a "using" statement for the
StreamWriter object, to ensure proper Flush()ing,
even in case of exceptions.
For source, see e.g.
http://svnbridge.codeplex.com/SourceControl/changeset/view/57698#776175

So there are some possibilities:
- subversion server is configuring its "update-report" to *not* do
  chunked transfers (i.e., doing Content-Length:-based transfers instead),
  and this is why there's no problem on its side (will check immediately)
  [SvnBridge enables response.SendChunked almost everywhere]
- subsequent chunks fail to arrive for some reason
  (premature response shutdown on server side?),
  and *this* is why svn client shuts down hard
  (will revisit my Wireshark tracing to verify)
- svn client HTTP response parsing library (neon?) implementation is
  buggy, taking parsing results of *incomplete*, to-be-amended chunks
  at face value (I'm currently betting on this one,
  but might change my opinion at any time)

Any other thoughts on this?

Thanks,

Andreas Mohr
Received on 2012-05-10 20:58:06 CEST

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.