I have domain.com and sub.domain.com pointing to the same server and I'm using mod_rewrite to rewrite URLs for sub.domain.com to the sub subdirectory. I have the following .htaccess file in the document root:

DirectoryIndex index.html index.php

# Prevent infinite rewrite loop.
# Send all requests addressing sub.domain.com...
RewriteCond %{HTTP_HOST} =sub.domain.com [NC]
# ...to the /sub directory.
RewriteRule ^ /sub%{REQUEST_URI} [QSA]

Within the sub directory I have index.php and no index.html, but requests to http://sub.domain.com seem to ignore index.php altogether and return 404. If I have index.html there, however, its is served. The only way I could get index.php to be served is to set

DirectoryIndex index.php

but that is not something I want to do for the entire site.

Oddly enough, URLs other than the document root exhibit normal DirectoryIndex behavior. For example, http://sub.domain.com/search tries looks for sub/search/index.html then sub/search/index.php before returning 404.

If I query the sub directory from the parent domain http://domain.com/sub, I'm able to see index.php, which leaves me completely dumbfounded with the issue.

I'd include the Apache error log, but I'm using shared hosting and have no way to increase logging verbosity. Also, I was unable to reproduce this error locally. The web hosting server is using Apache 2.4.3, and my local server is Apache 2.4.9.

  • 1
    try adding DirectoryCheckHandler On to your apache config? docs – howanghk Sep 2 '14 at 3:19
  • Oops, sorry for the delay. Looking at the docs for DirectoryCheckHandler, they state that "Releases prior to 2.4 implicitly act as if 'DirectoryCheckHandler ON' was specified." My local Apache server should have this directive OFF by default, and I guess the hosting server should have it OFF (since it's a 2.4 release). If DirectoryCheckHandler behavior is the rootcause, wouldn't I see it on both servers? – mxxk Jan 17 '15 at 8:40
  • And either way, I wouldn't be able to set DirectoryCheckHandler on the hosted server since it's not available in that version. – mxxk Jan 17 '15 at 8:40

I have a similar issue after upgrading to Ubuntu 14.04, which includes Apache 2.4.7.

Here is my workaround. Emulate mod_dir with mod_rewrite, and disable DirectoryIndex.

#DirectoryIndex index.html index.php index.htm
DirectoryIndex disabled

RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_FILENAME} /$
RewriteCond %{REQUEST_FILENAME}index.html -f
RewriteRule ^(.*)$ $1index.html  [L]

RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_FILENAME} /$
RewriteCond %{REQUEST_FILENAME}index.php -f
RewriteRule ^(.*)$ $1index.php  [L]

RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_FILENAME} /$
RewriteCond %{REQUEST_FILENAME}index.htm -f
RewriteRule ^(.*)$ $1index.htm  [L]

Hope this helps.

UPDATE: Upgrading to Apache 2.4.10 fix the issue for me.

Thanks to Ondřej Surý this can be done easily on Ubuntu 14.04 with apt:

add-apt-repository ppa:ondrej/apache2
apt-get update
apt-get install apache2

p.s. OP confirmed this is fixed in Apache 2.4.9 too.

  • I actually ended up using a nearly identical workaround. Thanks for posting it! – mxxk Jan 20 '15 at 5:04
  • Also I went with this workaround for another reason. I wanted directory URLs to not have trailing slashes (and explicitly removed them with mod_rewrite redirects). But because "DirectoryIndex will be evaluated only for directories requested with trailing slash" I used mod_rewrite again to emulate the indices. In retrospect it would have been much easier to keep the trailing slashes :) – mxxk Jan 20 '15 at 5:10

Set the DirectoryCheckHandler directive to ON.

The Apache docs say:

Available in 2.4.8 and later. Releases prior to 2.4 implicitly act as if "DirectoryCheckHandler ON" was specified.

mod_dir used to always perform its checks no matter which handler was set and now it must be explicitly enabled when not using the default handler.

  • mod_rewrite statements were in use, which was preventing DirectoryIndex from being checked. This fixed it. – Alastair Irvine Dec 4 '18 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.