mod_dav_svn sometimes needs to bail out in the middle of REPORT response it has
already begun transmitting due to some error raised as part of the processing
required to generate the response. When it does so, it drops an additional bit
of XML into the response stream which carries the error information, and then
that's the last bit of XML sent. (It doesn't bother trying to "cleanly close up
shop" and ensure that the rest of the XML body is well-formed with tag closures
and such.)
Generally, ra_serf seems to handle this well enough. But when mod_deflate is in
use, the server-generated error intended for the client's consumption gets
overshadowed by ra_serf's failure to satisfactorily manage the data stream at
all, and the user sees only something like:
$ svn up
Updating '.':
subversion/svn/update-cmd.c:168: (apr_err=120104)
subversion/libsvn_client/update.c:639: (apr_err=120104)
subversion/libsvn_client/update.c:579: (apr_err=120104)
subversion/libsvn_client/update.c:440: (apr_err=120104)
subversion/libsvn_wc/adm_crawler.c:858: (apr_err=120104)
subversion/libsvn_ra_serf/update.c:2515: (apr_err=120104)
subversion/libsvn_ra_serf/util.c:2028: (apr_err=120104)
subversion/libsvn_ra_serf/util.c:2009: (apr_err=120104)
subversion/libsvn_ra_serf/util.c:1574: (apr_err=120104)
svn: E120104: ra_serf: An error occurred during decompression
$
ra_serf should, you know, do better than that.
For a recipe script which exposes this problem, see issue #4021, and run the
script with a 1.7.7 server and mod_default enabled for the repository location.
Bug
Major