On Thu, May 10, 2012 at 08:57:33PM +0200, Andreas Mohr wrote: > 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." :-)
Oh, not really "Get Lost", but more like "not sure how we can really help you here." I ran into an SvnBridge bug a few years ago. AFAIK, they still have not fixed it, despite my pointer to the specific line in the bridge code causing the problem. Codeplex is not exactly well-maintained :-( >... > 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). Well, if the connection somehow indicates EOF in the middle the XML response, then I'm not surprised by that error. >... > 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 The Subversion client has been dealing with chunked encoding since its inception back in 2000. The Apache httpd server (and mod_dav(_svn)) have been sending responses that way forever. I really can't see that this is a problem on the client side. > 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] mod_dav_svn (ie. the standard svn server) does not specifically disable chunked transfers. However, there is a theoretical possibility that the httpd core understands the total response size and sends a Content-Length header and avoids chunking... but that is empircally not the case. Subversion can generate an update-report gigabytes in size. That cannot be held in memory in order to compute the length. Thus, it is streamed, which implies a chunked response. > - 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) I find this to be the most likely scenario. That the client is seeing an EOF for some reasons, which implies an unsuccessful completion of the XML parse. > - 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) Neon is very mature software. It's basic functionality was developed well over a decade ago. Subversion has also been using Neon for the past decade without any similar issue ("it just works"). As the guy who wrote Subversion's original HTTP code :-P ... I'd be very interested in tracking this down further, if you're willing. You mention Wireshark and investigation into the codeplex code, so I'm guessing this doesn't scare you at all :-) ... Let's move this to the dev@ list to continue research into the problem. It is likely on the TFS end, but if not... then we have more work to do. Would you mind trying the same scenario using ra_serf? It doesn't have any problems with chunked responses either, but it might give a different error which would help direct some further inquiry. Cheers, -g
