How to disable 301 redirect that adds trailing sla

Question

The Apache 2.2.20 automaticaly redirects all requests which are points to directories and has no trailing slash to the same URL with trailing slash, like shown below:

GET /some/path/to/dir HTTP/1.1
Host: www.some.org
...

301 Moved permanently
Location: http://www.some.org/some/path/to/dir/

In all cases it is a fine behavior, but I need to turn off this feature for one special folder (not for all), and can't find were I can do it.

Searching for 'Rewrite' rules tells founds nothing - only directive LoadModule mod_rewrite.so. Also, there is no .htaccess files in directories server in directory tree. Is there any other directives that make thing?

UPD1 I try to set up SVN trough HTTP with next config:

LoadModule dav_svn_module     /opt/libexec/mod_dav_svn.so
LoadModule authz_svn_module   /opt/libexec/mod_authz_svn.so

NameVirtualHost *:8000
<VirtualHost *:8000>
    ServerAdmin [e-mail]
    ServerName some.host.org
    DocumentRoot /path/to/wwwroot
    DAVLockDB /opt/var/lock/davlock/svndavlockdb

   <Directory /path/to/wwwroot>
        Options FollowSymLinks Indexes
#        #AllowOverride None
        Order allow,deny
        Allow from all
   </Directory>

   <Directory /path/to/wwwroot/svn>
        Options FollowSymLinks Indexes
        AllowOverride None
        Order allow,deny
        Allow from all
   </Directory>

    CustomLog /path/to/wwwroot/log/access_log.txt combined
    ErrorLog  /path/to/wwwroot/log/error_log.txt

    <Location /svn>

        #AllowOverride None
        #RewriteEngine Off
        #RewriteOptions AllowNoSlash
        DirectorySlash Off

        DAV svn
        SVNParentPath /path/to/wwwroot/svn
#        SVNListParentPath on

        AuthType Basic
        AuthName "Subversion Repository"
        AuthBasicAuthoritative Off
        AuthUserFile /path/to/wwwroot/svn/.htauthfile
        <Limit GET OPTIONS REPORT PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
            Require valid-user
        </Limit>
    </Location>

</VirtualHost>

UPD2 It seems that the "DirectorySlash Off" directive works only for "some.host.org/svn" and not works for "some.host.org/svn/repo1", "some.host.org/svn/repo2" etc - child directories not inherit this option.

UPD3 I try to add the following lines into config, but result is same - "DirectorySlash Off" work only for "/svn" and not for childs.

<LocationMatch "/svn/.*">
    DirectorySlash Off
</LocationMatch>

SOLVED Problem solved. This is a my mistake - I placed SVN repository root under DocumentRoot folder, so apache and web_dav can't understand, who must handle request. This applies to TortoiseSVN client at least.

Comments from SVN developers:

It means your httpd.conf is misconfigured. Usually this error happens when you've defined the Subversion virtual "location" to exist within two different scopes at the same time.

For example, if you've exported a repository as , but you've also set your DocumentRoot to be /www, then you're in trouble. When the request comes in for /www/foo/bar, apache doesn't know whether to find a real file named /foo/bar within your DocumentRoot, or whether to ask mod_dav_svn to fetch a file /bar from the /www/foo repository. Usually the former case wins, and hence the "Moved Permanently" error.

The solution is to make sure your repository does not overlap or live within any areas already exported as normal web shares.

It's also possible that you have an object in the web root which has the same name as your repository URL. For example, imagine your web server's document root is /var/www and your Subversion repository is located at /home/svn/repo. You then configure Apache to serve the repository at http://local.host/myrepo. If you then create the directory /var/www/myrepo/ this will cause a 301 error to occur.

Answer 1

Use mod_dir's DirectorySlash directive. Example from docs:

# see security warning in docs
<Location /some/path>
    DirectorySlash Off
    SetHandler some-handler
</Location>

Answer 2

Adding

DirectorySlash Off

to .htaccess worked fine for me.