On Thu, May 10, 2012 at 08:57:33PM +0200, Andreas Mohr wrote:
> 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.
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.
Received on 2012-05-11 11:49:47 CEST