WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 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: has-patch needs-testing
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.

Attachments (2)

20746.patch (648 bytes) - added by thomaswm 2 months ago.
Fix .htaccess by adding additional RewriteCond
20746.1.patch (1.0 KB) - added by thomaswm 2 months ago.
Alternative approach: Remove question mark from rewrite rule

Download all attachments as: .zip

Change History (28)

comment:1 @SergeyBiryukov3 years ago

  • Component changed from Rewrite Rules to Multisite

comment:2 @arkimedia3 years 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 @wonderboymusic3 years ago

  • Keywords reporter-feedback added

Example URL?

comment:4 @wpmuguru3 years 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 @jeremyfelt2 years 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 @jrfoell21 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 21 months ago by SergeyBiryukov (previous) (diff)

comment:7 @jeremyfelt21 months ago

  • Milestone set to Awaiting Review

comment:8 @mordauk20 months ago

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

comment:9 @mordauk20 months ago

  • Cc pippin@… added

comment:10 @ryanduff20 months ago

  • Cc ryan@… added

comment:11 @mordauk20 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 @jeremyfelt18 months ago

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

comment:13 @jrfoell17 months 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 17 months ago by jrfoell (previous) (diff)

comment:14 @wpmuguru17 months 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: @jrfoell17 months 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 @wpmuguru17 months 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 17 months ago by wpmuguru (previous) (diff)

comment:17 @jrfoell17 months 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]

comment:18 @lisota3 months ago

I can confirm this bug in subfolder Multisite in WP 4.1.1. Using the standard .htaccess rules for subfolder multisite.

Would be great if someone can get a fix pushed into the core .htaccess rules. I can't imagine that these redirect loops wouldn't have at least some negative impact on Apache performance.

@thomaswm2 months ago

Fix .htaccess by adding additional RewriteCond

@thomaswm2 months ago

Alternative approach: Remove question mark from rewrite rule

comment:19 @thomaswm2 months ago

  • Keywords has-patch needs-testing added

I can also confirm this bug in my setup (WordPress Multisite, sub-directory install).

I've added patches for both solutions that were suggested in this ticket.

comment:20 @slackbot3 weeks ago

This ticket was mentioned in Slack in #core by jorbin. View the logs.

comment:21 follow-ups: @jorbin3 weeks ago

This needs some further testing, along with some clearer reproduction steps. We need to be very careful to not break any of the existing behavior.

When this is fixed, we should also do a make/core post with the changes since this will only change the rewrite rules for new sites.

comment:22 in reply to: ↑ 21 @lisota3 weeks ago

Replying to jorbin:

This needs some further testing, along with some clearer reproduction steps. We need to be very careful to not break any of the existing behavior.

When this is fixed, we should also do a make/core post with the changes since this will only change the rewrite rules for new sites.

We are experiencing this issue with a Multisite subdirectory install, with the same reproduction steps in https://core.trac.wordpress.org/ticket/20746#comment:11. Our error logs fill daily with "Request exceeded the limit of 10 internal redirects due to probable configuration error."

Our installation was originally a single site that was upgraded to multisite. Upgrading to multisite caused this error on our site, though multiple commenters above describe this issue on fresh multisite installs as well.

comment:23 in reply to: ↑ 21 ; follow-up: @wpmuguru3 weeks ago

Replying to jorbin:

This needs some further testing, along with some clearer reproduction steps. We need to be very careful to not break any of the existing behavior.

I believe you can reproduce this by requesting any non-existant file from a theme folder in a sub folder install

http://example.com/subsite/wp-content/themes/twentyfifteen/image-that-does-not-exist.jpg

When this is fixed, we should also do a make/core post with the changes since this will only change the rewrite rules for new sites.

This change would only affect new installs. .htaccess is not updated on WP updates.

comment:24 in reply to: ↑ 23 @thomaswm3 weeks ago

Replying to wpmuguru:

Replying to jorbin:

This needs some further testing, along with some clearer reproduction steps. We need to be very careful to not break any of the existing behavior.

I believe you can reproduce this by requesting any non-existant file from a theme folder in a sub folder install

http://example.com/subsite/wp-content/themes/twentyfifteen/image-that-does-not-exist.jpg

That's right. But not only the themes folder is affected. This problem occurs for any non-existent file in wp-content and any subfolder of wp-content.

I tried to explain this in a bit more detail here.

comment:25 @jeremyfelt3 weeks ago

#28164 was marked as a duplicate.

comment:26 @jeremyfelt3 weeks ago

#30588 was marked as a duplicate.

Note: See TracTickets for help on using tickets.