subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: Unexpected HTTP status 400 'Bad request'.
Date Tue, 08 Dec 2015 15:28:21 GMT
This is just the Subversion operational log generated by mod_dav_svn. The interesting things
would be in the apache access and/or error logs.

(Depending on the configuration of your apache these could be the same logfile)

 

The operational log just shows successful Subversion operations, so that doesn’t tell us
much why a request failed.

 

                Bert

 

 

From: Chris Capon [mailto:ttabyss@gmail.com] 
Sent: dinsdag 8 december 2015 15:29
To: users@subversion.apache.org
Subject: Re: Unexpected HTTP status 400 'Bad request'.

 

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@gmail.com> mailto:ymartin1040@gmail.com] 
Sent: dinsdag 8 december 2015 11:06
To:  <mailto:users@subversion.apache.org> 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

 


Mime
View raw message