WordPress.org

Make WordPress Core

Opened 23 months ago

Last modified 8 weeks ago

#20746 reopened defect (bug)

Accessing non-existing theme folder in Network install gives 500 error

Reported by: arkimedia Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.3.2
Component: Rewrite Rules Keywords:
Focuses: multisite Cc:

Description

Accessing non-existing theme folder in Network install gives 500 error and following error in error log: Request exceeded the limit of 10 internal redirects due to probable configuration error.

Change History (17)

comment:1 SergeyBiryukov23 months ago

  • Component changed from Rewrite Rules to Multisite

comment:2 arkimedia23 months ago

Addition: The problem occurs at least in subdirectory installs. I have tested also with the fresh network install with default .htaccess rules and no plugins installed and I got same response from the server.

comment:3 wonderboymusic18 months ago

  • Keywords reporter-feedback added

Example URL?

comment:4 wpmuguru17 months ago

Any instances I've seen of this were a result of rewrite rules in the .htaccess. A network upgraded from WordPress MU might exhibit this behavior.

comment:5 jeremyfelt8 months ago

  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Sounds specific to server/site configuration. Closing, but feel free to reopen if it can be reproduced.

comment:6 jrfoell7 months ago

  • Cc justin@… added
  • Resolution worksforme deleted
  • Status changed from closed to reopened

Here's how to reproduce:

  1. Create a sub-directory multi-site installation per normal
  2. Try to load a fictitious file from wp-content such as:

http://example.com/wp-content/uploads/2013/10/test.jpg

  1. Observe "500 Internal Server Error" due to "Request exceeded the limit of 10 internal redirects due to probable configuration error."

I believe this is because after this rule is applied:

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

Apache tries to rewrite (internally) from "wp-content/uploads/2013/10/test.jpg" to "/wp-content/uploads/2013/10/test.jpg" with a beginning slash. Then the aforementioned rule gets applied again because it matches - creating a loop.

Expected result: 404 Page

Last edited 7 months ago by SergeyBiryukov (previous) (diff)

comment:7 jeremyfelt6 months ago

  • Milestone set to Awaiting Review

comment:8 mordauk5 months ago

I've seen this happen on 3 different multi-site installs, all running on different servers / hosts.

comment:9 mordauk5 months ago

  • Cc pippin@… added

comment:10 ryanduff5 months ago

  • Cc ryan@… added

comment:11 mordauk5 months ago

Ron Rennick has suggested that adding RewriteCond %{REQUEST_URI} !^wp-(content|admin|includes).*$ above RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L] might solve the issue.

I'm running the modified version on two live sites now but haven't confirmed for sure if it resolves it or not.

comment:12 jeremyfelt3 months ago

  • Component changed from Multisite to Rewrite Rules
  • Focuses multisite added

comment:13 jrfoell8 weeks ago

I confirmed that the Ron Rennick / Pippin suggestion did not work for me on Apache 2.4.6 (added to a fresh WP 3.8.1 multisite subfolder install). The following seems to work, but it is not elegant and I haven't determined if it has other adverse effects:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
# start new
RewriteCond %{REQUEST_URI} ^/wp-(content|admin|includes).*$
RewriteRule ^ - [S=2]
# end new
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]`

The key is really noticing the difference between "wp-content/uploads/2013/10/test.jpg" and "/wp-content/uploads/2013/10/test.jpg" - with or without a beginning slash - so Apache doesn't go looking for a file outside of the webroot.

Some of this seems to go against the documentation regarding "Per-directory Rewrites" found here: http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriterule specifically the second-to-last point:

The removed prefix always ends with a slash, meaning the matching occurs against a string which never has a leading slash. Therefore, a Pattern with ^/ never matches in per-directory context.

But I could be reading it wrong.

Last edited 8 weeks ago by jrfoell (previous) (diff)

comment:14 wpmuguru8 weeks ago

The key is really noticing the difference between "wp-content/uploads/2013/10/test.jpg" and "/wp-content/uploads/2013/10/test.jpg" - with or without a beginning slash - so Apache doesn't go looking for a file outside of the webroot.

If you do not have the RewriteBase / at the beginning of your .htaccess (per standard WP .htaccess) then

RewriteCond %{REQUEST_URI} ^/wp-(content|admin|includes).*$

would work. If you do have it then the requested URL would need to be http://example.com//wp-content.... for the rewrite condition to be met.

Since the standard rewrite rules for the .htaccess are for a rewrite base of / (or /some-path/) then the correct rule is

RewriteCond %{REQUEST_URI} ^wp-(content|admin|includes).*$

If you are missing the RewriteBase that would explain why the rule Pippin posted above didn't work for you.

comment:15 follow-up: jrfoell8 weeks ago

Thanks Ron... I amended my comment to show the full .htaccess I'm using.

Were you able to confirm that your suggested change (from comment 11) fixes the issue with a new WP 3.8 multi-site subfolder installation?

comment:16 in reply to: ↑ 15 wpmuguru8 weeks ago

Replying to jrfoell:

Thanks Ron... I amended my comment to show the full .htaccess I'm using.

In the full htaccess above the rewrite condition

RewriteCond %{REQUEST_URI} ^/wp-(content|admin|includes).*$`

will only be met if the requested path begins with //. The RewriteBase directive tells the rewrite engine to start rewriting after the base value.

Secondly, that .htaccess isn't what I suggested to Pippin. What I suggested was

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

Looking at the original rule it would probably be easier to remove the ? from the original rule

RewriteRule ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]
Last edited 8 weeks ago by wpmuguru (previous) (diff)

comment:17 jrfoell8 weeks ago

I verified that the first (original) suggestion from ticket:20746#comment:11 (reiterated in ticket:20746#comment:16) still produces a 500 error on a sub-folder multi-site.

The second suggestion from ticket:20746#comment:16 does seem to work, but I have not verified if it has any other adverse effects:

RewriteRule ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]
Note: See TracTickets for help on using tickets.