subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <philip.mar...@wandisco.com>
Subject serf errors on responses bigger than 4GB
Date Wed, 01 Oct 2014 10:48:38 GMT
Andreas Stieger <andreas.stieger@gmx.de> writes:

> I
> will once again point to the serf issues below and httpd/network config.
> https://code.google.com/p/serf/issues/detail?id=152
> https://code.google.com/p/serf/source/detail?r=2419

Andreas identified a bug in serf that causes decompression to fail when
the compressed size is bigger than 4GB. This bug has been fixed on trunk
but not in any release.  This bug does not affect commit but does affect
checkout/update.

In my testing a commit of a 5GB /dev/urandom file over HTTP using serf
1.3.x works with compression both disabled and enabled.  A checkout over
HTTP using serf 1.3.x fails:

  svn: E120104: ra_serf: An error occurred during decompression

I also tried the checkout with compression disabled by the client and
saw the error:

  svn: E120106: ra_serf: The server sent a truncated HTTP response body.

but this turned out to be the known mod_deflate memory leak causing the
server to abort.  With compression disabled on the server the
uncompressed checkout works.

Doing a search I see users reporting both the above serf errors.  The
way to fix the decompression error is to disable compression.  This can
be done on the client if the server is a recent 2.4 as it is not
affected by the mod_deflate bug.  If the server is older then a client
disabling compression will probably cause the truncated error and the
fix is to disable mod_deflate on the server or to revert to a 1.7/neon
client.

I merged r2419 to my 1.3.x build and it fixes the compressed checkout.
Are there any plans for a serf release that includes this fix?

- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Mime
View raw message