201 Created responses from MKCOL or COPY losing their bodies

I'm using a Big-IP device as a load balancer in front of some Subversion application servers (Apache httpd), and am finding that sometimes a strange thing happens when attempting to perform certain Subversion operations. Without going into the details of Subversion itself, suffice it to say that my Subversion client (running on, say, my laptop) issues a WebDAV MKCOL request to the server. The request is simple enough:

MKCOL /project/!svn/txr/734-mc/sandbox/dir HTTP/1.1
Host: ***REDACTED**
Authorization: Basic Y21waWxhdG86Y21waWxhdG8=
User-Agent: SVN/1.8.4-dev (x86_64-unknown-linux-gnu) serf/1.2.1
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops

I've configured Big-IP to add some extra headers as the request passes through, so what hits the actual SVN server is exactly like the above, but also contains these two headers:

X-Forwarded-For: ***REDACTED***
X-Forwarded-Proto: http

The response from the SVN server looks like so:

HTTP/1.1 201 Created
Date: Mon, 28 Oct 2013 11:02:44 GMT
Server: Apache/2.2.15 (CentOS)
Location: ***REDACTED***/project/!svn/txr/734-mc/sandbox/dir
Content-Length: 296
Content-Type: text/html; charset=ISO-8859-1

❬!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"❭
❬html❭❬head❭
❬title❭201 Created❬/title❭
❬/head❭❬body❭
❬h1❭Created❬/h1❭
❬p❭Collection /project/!svn/txr/734-mc/sandbox/dir has been created.❬/p❭
❬hr /❭
❬address❭Apache/2.2.15 (CentOS) Server at ***REDACTED*** Port 80❬/address❭
❬/body❭❬/html❭

...which is correct. Subversion has successfully created the new collection in its commit transaction, and tells the client this fact using a "201 Created" response that has an HTML body.

The problem I see -- in certain situations only, mind you -- is that the body never makes it back to the client! Big-IP appears to be dropping the response body. What is actually received back at the client is exactly the same as the above -- with the Content-length header intact -- but with no response body. Now, the Subversion client doesn't really care about that response body, anyway. But the Serf HTTP library atop which Subversion is built does care that the HTTP response claims to have a body (per "Content-length: 296") but, in fact, does not. This results in a low-level error which trickles up to the Subversion client and ultimately to the end user, and the overall operation fails.

I don't recall configuring anything on the load balancer that would chomp response bodies. And MKCOL is not the only request type which fails like this. I've seen COPY operations -- those which also result in 201 Created responses which have non-empty bodies -- fail in similar fashion.

Does any of this ring a bell with anyone else?