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

Reply via email to