> -----Original Message----- > From: Chris Capon [mailto:ttab...@gmail.com] > Sent: dinsdag 8 december 2015 14:47 > To: users@subversion.apache.org > Subject: Re: Unexpected HTTP status 400 'Bad request'. > > On 2015-12-08 05:06, Yves Martin wrote: > > Hello > > > > Is your repository served read-write by other services like svnserve > > or eventually through SSH in addition to Apache HTTPS access ? > I'm sorry. I don't understand what this asks. Permissions are > controlled by a .apache_auth and .apache_htpasswd file (in addition to > client certificates). The .apache_auth file has the folder defined as > 'rw' for my user id. > > > > If so you have to check your repository file permissions: owner, group > > and modes (for instance g+w or g+s...) > All the file level permissions are set to rwxr-xr-x (755) and both owner > and group are www-data, the user id under which the Apache2 service runs. > > > > 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. > Repository Format: 5 > Compatible With Version: 1.9.0 > Repository Capability: mergeinfo > Filesystem Type: fsfs > Filesystem Format: 7 > FSFS Sharded: yes > FSFS Shard Size: 1000 > FSFS Shards Packed: 0/3 > FSFS Logical Addressing: no > Configuration File: /root/subversion/root/repository/db/fsfs.conf > > > > > Maybe you should use "svnadmin upgrade" to get some new features > > properly enabled with Subversion 1.9, > After running > svn upgrade /root/subversion/root/repository > > The response was "Upgrade completed." But an svn checkout gives the > same error: > > svn: E175002: Unexpected HTTP status 4000 'Bad request' on > '/svn/repository/!svn/rvr/1903/dev...' > > Again, at a random file about 5 or 6 files in. > > or even use dump/load procedure (or svnsync) to get your repository > > ready (and optimized) for Subversion 1.9. > We tried this in a previous e-mail (see for details).
Are you using some kind of (caching) proxy server when you connect to the server? You are focusing your search to a disk problem (probably caused by hints on this list), while you are trying to determine what causes a 'bad HTTP request' error. Bad requests on these urls may be caused by sending bad header values... I've seen those before when using nginx as proxy with a too strict caching policy. Bert