1

I'm getting the following error, when attempting to commit large files (multi-gigabyte) to a new local installation of VisualSVN 2.5.2 Server on a Windows XP machine.

"413 Request Entity Too Large"

I'm using Windows authentication, and I've already added the following settings (and then restarted the server) to httpd-custom.conf:

LimitXMLRequestBody 0
LimitRequestBody 0

If it matters, I'm using TortoiseSVN as a client.

Is there something else that needs to be done to get VisualSVN Server to accept large files?

Update:

Contents of the SVNServer Event Viewer:

1/13/2012 3:31:45 PM VisualSVN Server 2.5 Error Apache 1001 CORP\sam.johnson IOMFOX0960L Could not get next bucket brigade [500, #0] [client 10.155.60.53]
1/13/2012 3:31:45 PM VisualSVN Server 2.5 Error Apache 1001 CORP\sam.johnson IOMFOX0960L Invalid Content-Length [client 10.155.60.53]

Kenny Rasschaert
  • 9,045
  • 3
  • 42
  • 58
Sam Johnson
  • 139
  • 1
  • 8

2 Answers2

3

"413 Request Entity Too Large" error on commit is rather a client's issue than the server's one.

Subversion clients use neon library for network communication by default. This library does not support transmission large files to Subversion server correctly.

As a workaround you can switch from neon to serf library. Perform the steps on client's machine:

  1. Open file %APPDATA%\Subversion\servers
  2. Find [global] section
  3. Add following option to the [global] section: http-library=serf
  4. Save servers file and try to commit again
Bart De Vos
  • 17,911
  • 6
  • 63
  • 82
bahrep
  • 687
  • 1
  • 9
  • 27
  • This answer is also correct - I accepted the above one for including the explanation that confirmed that it was a client issue. Thanks for your input! – Sam Johnson Jan 16 '12 at 12:33
2

You're hitting an error on this chunk of validation code, in http_filters.c:

/* Protects against over/underflow, non-digit chars in the
 * string (excluding leading space) (the endstr checks)
 * and a negative number. */
if (apr_strtoff(&ctx->remaining, lenp, &endstr, 10)
    || endstr == lenp || *endstr || ctx->remaining < 0) {

    ctx->remaining = 0;
    ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, f->r,
      "Invalid Content-Length");

    return bail_out_on_error(ctx, f, HTTP_REQUEST_ENTITY_TOO_LARGE);
}

So, your removal of the request body limit was successful. It looks like the client is at fault; Tortoise seems to be be sending invalid data in the Content-Length header. Is there any way that you can capture the full HTTP request (it'll need to be unencrypted http, and you'll need a capture tool like wireshark) to inspect what it's sending in that header?

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • Looks like the client (TortoiseSVN) is sending an negative value for some reason. There's a few threads about it here and there, but no resolution that I've been able to find. Should I leave this question up, or take it down and post a more specific question (since it's the client's issue, not the server) – Sam Johnson Jan 15 '12 at 02:09
  • Well, first thing is that I'd recommend is to seriously reconsider storing multi-gig files in SVN.. it's really not made for that. That said, it looks like the neon library is the cause, and switching to serf may resolve it - see [here](https://groups.google.com/group/subversion_users/browse_thread/thread/cea04dc4694ba64a). – Shane Madden Jan 15 '12 at 02:44
  • Good call - that's exactly what it was, and confirmed by VisualSVN Server support as well. Thanks for your help! – Sam Johnson Jan 16 '12 at 12:31