Infinite redirect loop due to caching?


A colleague and I recently redesigned a site that had its home page at index100.html, instead of index.html. Due to browser caching, even though the new site is live, users are typing in the domain name and are being pointed to the index100.html page. Since it is unreasonable to expect our users to know that they need to reload the site without pulling from the cache, I set up a simple redirect in .htaccess.

The redirect works, but it seems if the user has visited the old site, that my rule creates an infinite loop between what’s in the browser’s cache and what’s in the .htaccess file. Is there anyway to force the browser to essentially ignore the cache? Is a separate rule in the .htaccess file the best (or even an acceptable) way to go about fixing this?

Matt W


Ah, you’ve discovered the problem with long expiration times (not cacheing - if it’s serving from your cache, EMPTY the cache files and don’t serve them for a week or so).

What do you have in your .htaccess? There may be some way to work around the redirection’s looping.




I have a simple redirect set up:
Redirect /index100.html

Thanks for your help!



What is the DirectoryIndex for your document root? If it’s index100.html, then you’ll have a loop. I think that the simplest thing for you to do is CHANGE the DirectoryIndex to:

DirectoryIndex index.php index.html index100.html

That will make your default file the FIRST file in the list which exists (so index100.html WILL be redirected to index.php).

As an aside, I believe you’ll get slightly better service from your mod_alias Redirect by adding a trailing / (assuming that you don’t want to use



Thanks David. Currently the DirectoryIndex is not set in the .htaccess file. However, unless I use the DirectoryIndex in conjunction with my first Redirect rule, index100.html is not redirected to index.php. This site uses a CMS that also uses the .htaccess file to control the URL structure. It seems to be forcing everything on the site to go through /index.php. In this case, I assume it is necessary to use both the Redirect and DirectoryIndex rules to prevent the infinite loop?

Here is that additional code I mentioned that is being used by the site’s CMS:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/|\\.php|\\.html|\\.htm|\\.feed|\\.pdf|\\.raw|/[^.]*)$  [NC]
RewriteRule (.*) index.php
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

Thanks again for your help,


Apache has a LOT of directives but the DirectoryIndex is normally defaulted to index.html and index.htm. I ALWAYS change that to add index.php as the FIRST in that list.

As for your question about a loop, I have to say that I have no idea how you’re serving index100.html when the domain is requested. That simply HAS to be a DirectoryIndex directive! Therefore, your Redirect /index100.html is redirecting to the DirectoryIndex which, if it’s set to index100.html, you’ve created a loop. Resetting the DirectoryIndex solves this problem for you.

As for the CMS code (it looks like an amplified WordPress code - the extensions and Authorization are not generally used), it is used AFTER the DirectoryIndex BECAUSE core directives (i.e., NOT mod_rewrite) take precedence.



Thanks David. It’s odd that it would be using index100.html as the DirectorIndex, since the redesigned/rebuilt site is on a completely different host. I assumed that browsers were somehow caching redirects. In any case, I specifically set the DirectoryIndex to index.php. It’s good to know that it defaults to index.html or index.htm. I’ll keep that in mind in the future.

Thanks again,