WordPress.org

Ready to get started?Download WordPress

Forums

Multisite: default .htaccess rules cause infinite loop (17 posts)

  1. Greg
    Member
    Posted 3 years ago #

    I have a WP3.0.1 multisite install that is using subdirectories. I'm using Apache.

    All is working fine, except that when there is a request to a non-existent path below "wp-*" the server throws an internal error because the .htaccess rule causes an infinite loop.

    For example: http://yourdomain.com/wp-content/random/missing-page.php

    I am using the default .htaccess rules found here: http://codex.wordpress.org/Create_A_Network

    This is a problem because bots outside my control are looking for pages that don't exist and each time this happens an internal server error occurs.

    I saw this thread, but I don't have any duplicate htaccess files so it does not apply.

    Any ideas? I tried a few other sites that use WPMU and on some of them I found the same issue, so I'm not alone.

  2. tdjcbe
    Member
    Posted 3 years ago #

    It would be helpful if you copied and pasted the actual specific error you are receiving out of your webserver's error logs.

    Hmmm, I get 404's when I try in on one of my installs.

  3. Greg
    Member
    Posted 3 years ago #

    tdjcbe, here is the error:

    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.

  4. Greg
    Member
    Posted 3 years ago #

    tdjcbe, is Apache your web server, and is it a subdirectory install?

  5. Also, paste your full htacess here. Yeah, I know you said you're using the one from that URL, but let's make sure you don't have something conflicting :)

    Can you give us your URL? Have you turned off all plugins?

  6. Greg
    Member
    Posted 3 years ago #

    ipstenu, the problem is present with the exact htaccess I pointed to in the codex. No additional rules to cause conflicts.

    The site in question is http://youlookfab.com, which is running several plugins. But I have tested this on our staging server and the problem is present with all plugins deactivated.

  7. Those htacess rules are the default for a root folder install, so sometimes we want to ask weird questions :) bear with us.

    Rename the file to old.htaccess and see if you can go to the wp-admin URL? Also, can you list your plugins? I see you have a login page design plugin, and we have seen that error MANY times with some plugins. So which one are you using to jigger your login page? :)

  8. And the error message you have states to bump up the rewrite limit past 10. :) Which is kinda low. (but normal on shared hosts).

    But also - wordpress is written to only "see" the actual physical folders under wp-content, not any other random ones.

  9. MRPH. I need more coffee. Yeah, what Andrea said.

  10. Greg
    Member
    Posted 3 years ago #

    Andrea, can you explain why the rewrite limit would need to be higher than 10? That error message tells you to bump the limit past whatever you have set in httpd.conf. It defaults to 10 because once mod_rewrite has repeated the rewrite 10 times there is a pretty good chance it is in a loop. For completeness sake I set the limit to 50 and this doesn't change anything (except the error message where the 10 is replaced with 50 of course).

    BTW, the error I get on my development server is similar, but is issued by mod_rewrite:

    mod_rewrite: maximum number of internal redirects reached. Assuming configuration error. Use 'RewriteOptions MaxRedirects' to increase the limit if neccessary.

    And I do understand that these directories are virtual, but that doesn't explain why it would generate a server error instead of a 404. Or am I missing something?

    ipstenu, are the plugins relevant if I can disable every single one of them and still see this issue?

    There is something strange happening here because if I remove the following line from the htaccess then the error goes away:

    RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]

    Of course, this is the line that makes the admin page accessible for the non primary blogs, so it is necessary.

    The strange thing is that this line shouldn't kick in for a path off the primary blog's "wp-content" because the pattern matches "subfolder/wp_content" where "subfolder" here is one or more characters.

    I know this is all a little obscure, but I was hoping that someone with experience of the issue could point me in the right direction. I'm pretty sure there are many multisite installs out there doing this and none the wiser, because you need to be watching your server error log to even know it is happening.

    UPDATE: Should have done this earlier, but I have created a brand new, bog standard multisite install on my development server. No plugins activated, and the default MU home page theme. The same problem occurs.

  11. Greg
    Member
    Posted 3 years ago #

    I'm starting to think this is a bug in the default htaccess rules, perhaps related to the way mod_rewrite implicitly handles files/directories that aren't found.

    I don't know mod_rewrite well enough, but something like this:

    1. some implicit rule rewrites "/wp-content/folder/missing.php" to "/something/wp-content/folder/missing.php"
    2. rule in the default .htaccess rewrites "/something/wp-content/folder/missing.php" to "/wp-content/folder/missing.php"
    3. repeat until recursion limit is reached

    If I add a 404 handler rule to the .htaccess (like below) then the internal server error goes away, which supports the theory but doesn't prove it.

    RewriteCond %{SCRIPT_FILENAME} !-f
    RewriteCond %{SCRIPT_FILENAME} !-d
    RewriteRule ^(.*)$ index.php/$1

    I have done this on my development server but still not production because I'd like to test more thoroughly.

    Any input on the real reason that mod_rewrite is looping infinitely with the default htaccess rules would be much appreciated. I'd love to understand what is happening here.

  12. Andrea, can you explain why the rewrite limit would need to be higher than 10?

    Cuz in the past with some people on shared hosts, bumping it up has helped.

    Yes, this is pretty obscure. If it's really bugging you, file a trac ticket. :)

  13. Greg
    Member
    Posted 3 years ago #

    A trac ticket is probably the right thing at this point.

    Andrea, have you checked whether your subdirectory based multisite installs generate these internal server errors for files not found below "wp-*"?

  14. Yep, one of 'em does.

    But realistically, the likelihood of someone trying to access files that way is slim.

    on the other hand, they do have a rewrite rule in place at wordpress.com that correctly pulls up a page not found. but they aren't on apache, they're on lightspeed.

  15. Greg
    Member
    Posted 3 years ago #

    Thanks Andrea.

    I find that there are quite a few requests coming in for outdated resources (e.g. assets in themes we no longer use) and with enough of these I'm worried that it will start impacting server performance.

    Yes, I've also noticed that LiteSpeed doesn't have this issue. Or nginx, which is what WordPress.com is using right now.

  16. Lighttpd is what I meant. They use nginx for serving caches files, I think. Can't quite remember last time we were talking to Barry.

  17. Note the rewrite rule right under this one:

    RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]

    put a # sign in front of the next line, see if the problem goes away.

    this fix only works on a subdomain install. If you've upgraded mu, ypou probably have rewrite rules in there for a subfolder install.

Topic Closed

This topic has been closed to new replies.

About this Topic