Apache 2.4 – Request exceeded the limit of 10 internal redirects due to probable configuration error

4 Views

I’m running Apache 2.4 (64bit) and PHP 5.4.15 on windows Server 2008 R2 Enterprise and have noticed the following error in the Apache error log: 

AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

I have a multisite install of WordPress running and I think the error is coming from an error in the htaccess rewrites.

Read More

Looking at this post:
Request exceeded the limit of 10 internal redirects due to probable configuration error.?

They suggest to replace this: 

# BEGIN WordPress
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>
# END WordPress

with this piece of code, courtesy of Scott Yang: 

<IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteBase /
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule ^(.+)$ /index.php/$1 [L,QSA]
</IfModule>

However, my WordPress htaccess looks a little different so I dont just want to replace my code just in case I inadvertently replace something that I need.

Here is my htaccess: 

# BEGIN WordPress
<IfModule mod_rewrite.c>
Options +FollowSymLinks -MultiViews
Header set Access-Control-Allow-Origin "*"
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*.php)$ $1 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress

Can anyone suggest what I need to change?

Post Views: 4

Related posts

Leave a Reply

4 comments

  1. This problem can be caused by requests for certain files that don’t exist. For example, requests for files in wp-content/uploads/ where the file does not exist.

    If this is the situation you’re seeing, you can solve the problem by going to .htaccess and changing this line:

    RewriteRule ^(wp-(content|admin|includes).*) $1 [L]

    to:

    RewriteRule ^(wp-(content|admin|includes).*) - [L]

    The underlying issue is that the rule above triggers a rewrite to the exact same url with a slash in front and because there was a rewrite, the newly rewritten request goes back through the rules again and the same rule is triggered. By changing that line’s “$1” to “-“, no rewrite happens and so the rewriting process does not start over again with the same URL.

    It’s possible that there’s a difference in how apache 2.2 and 2.4 handle this situation of only-difference-is-a-slash-in-front and that’s why the default rules provided by WordPress aren’t working perfectly.

  2. You’re getting into looping most likely due to these rules:

    RewriteRule ^(.*.php)$ $1 [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]

    Just comment it out and try again in a new browser.

  3. Solved this by adding following:

    RewriteCond %{ENV:REDIRECT_STATUS} 200 [OR]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

  4. In our case, an editor created a custom post type and a custom content type with the same slug. We fixed it by deleting one and resaving permalinks in [ WordPress › Tools › Settings ].

    Hope this helps anyone.