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]

2
  • Can you check what's recorded in the Apache error log when this occurs? Commented Jan 13, 2012 at 20:36
  • I've updated my question with the Apache Errors. Thanks for the recommendation, I'll start researching them now. Commented Jan 13, 2012 at 20:44

2 Answers 2

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?

3
  • 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) Commented Jan 15, 2012 at 2: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. Commented Jan 15, 2012 at 2:44
  • Good call - that's exactly what it was, and confirmed by VisualSVN Server support as well. Thanks for your help! Commented Jan 16, 2012 at 12:31
4

Update your SVN client to the latest version and see if it helps. Modern SVN clients use the serf library by default that isn't affected by this issue.

Old answer

"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
1
  • 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! Commented Jan 16, 2012 at 12:33

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.