Usually you wouldn’t get ‘bad request’ errors from httpd unless Subversion
sends a bad request. Server side errors as disk io are usually reported by
other error codes, such as 500.
Most bad cases of status 400 are caused by firewall and antivirus products that
somehow alter requests in unexpected ways. Another ‘expected’ case of this
error is when Subversion sends too many headers to the server; we see this in
some commits of subtrees with hundreds of locks. The investigation for this
error code should start in the server log.
Except for that too much header data, the Subversion client should never
generate a request that the server thinks is ‘bad’. That is what it tells with
status 400.
But as noted before: more details should be in the server log (and often in the
response body itself… but if there was usable data there Subversion should have
noted that)
Bert
From: Yves Martin [mailto:ymartin1...@gmail.com]
Sent: dinsdag 8 december 2015 11:06
To: users@subversion.apache.org
Subject: Re: Unexpected HTTP status 400 'Bad request'.
Hello
Is your repository served read-write by other services like svnserve or
eventually through SSH in addition to Apache HTTPS access ?
If so you have to check your repository file permissions: owner, group and
modes (for instance g+w or g+s...)
I guess your repository has been created long ago with a previous version of
Subversion.
What is your repository format version ? Are some revisions packed ? Use
svnadmin info.
Maybe you should use "svnadmin upgrade" to get some new features properly
enabled with Subversion 1.9,
or even use dump/load procedure (or svnsync) to get your repository ready (and
optimized) for Subversion 1.9.
Regards
--
Yves Martin
