Hi Bert.
The only log I know of is under /var/log/apache2/subversion.log, and
when I issue a checkout, I get only two lines in it:
[08/Dec/2015:09:24:53 -500] myself get-inherited-props /dev/trunk r3066
[08/Dec/2015:09:24:53 -500] myself checkout-or-export /dev/trunk r3066
If the error were caused by a firewall or antivirus software, would it
still make sense that the checkout begins and gets several files in
before failing? Also, to try and eliminate that possibility, I've been
performing the checkout tests on the subversion server machine.
On 2015-12-08 05:37, Bert Huijben wrote:
>
> 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:ymartin1040_at_gmail.com]
> *Sent:* dinsdag 8 december 2015 11:06
> *To:* users_at_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
>
Received on 2015-12-08 15:28:55 CET