WordPress.org

Make WordPress Core

Opened 11 years ago

Closed 15 months ago

Last modified 15 months ago

#12175 closed defect (bug) (wontfix)

Issues using mod_rewrite / mod_cache together (apache)

Reported by: hurikhan77 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Rewrite Rules Keywords: close
Focuses: performance Cc:

Description

We run several wordpress deployments on a server which also runs mod_cache for performance reasons. However, using wordpress supplied rewrite configuration creates unwanted caching artefacts in mod_cache because the default rewrite configuration rewrites ALL requests into a single URL instead of unique/canonical URLs. The problem is that mod_cache only sees the final rewritten URL upon caching which is obviously unique for all request. A simple change in htaccess however works around this problem:

Change "RewriteRule . /index.php [L]" into "RewriteRule ^(.*)$ /index.php/$1 [L]". It should not hurt the rest of the wordpress installation but allows for high performance reverse proxying of wordpress installations using mod_cache.

I'm assigning this major severity as the original RewriteRule rule can lead to unwanted content disclosure and can result in wrong content for a URL being delivered.

This bug triggers in mod_cache as soon as proper combinations of HTTP caching headers are sent (Expires, Cache-Control, etc). However, it will not trigger in default apache (read "non-mod_cache") configurations, only when you apply high-performance content caching configurations within apache in combination with mod_rewrite.

Change History (7)

#1 @f00f
11 years ago

This problem is very, very annoying. Since I applied the suggested fix two weeks ago it never happened on my blog again.

#2 @nacin
11 years ago

  • Keywords close added
  • Severity changed from major to normal

I'm not sure there's a need to add a backreference when, if you're setting up mod_cache, you can clearly make this change as part of optimizing the server. WordPress only provides simple, default rewrite rules -- many advanced setups require much more sophisticated rules which are optimized for your situation.

In a typical install, the backreference would be useless and ironically a performance hit.

#3 follow-up: @nacin
11 years ago

  • Milestone Unassigned deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#4 in reply to: ↑ 3 @drzraf
4 years ago

  • Focuses performance added

Then FallbackResource could be used as well.
But still, having a mod_cache compatible default would be nice.
Care about reconsidering? Is the performance impact measurable?

side note: when it comes to mod_cache, there are more important performances issues ;)

#5 in reply to: ↑ description ; follow-up: @wasabi_flagg
15 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I tried to change

"RewriteRule . /index.php [L]"

into

 "RewriteRule ^(.*)$ /index.php/$1 [L]"

but Wordpress gives me "File not found" for every page but the homepage
Apache 2.4.25
Mod_Cache_Disk
Php7-FPM
Wordpress 5.2.2

Replying to hurikhan77:

We run several wordpress deployments on a server which also runs mod_cache for performance reasons. However, using wordpress supplied rewrite configuration creates unwanted caching artefacts in mod_cache because the default rewrite configuration rewrites ALL requests into a single URL instead of unique/canonical URLs. The problem is that mod_cache only sees the final rewritten URL upon caching which is obviously unique for all request. A simple change in htaccess however works around this problem:

Change "RewriteRule . /index.php [L]" into "RewriteRule ^(.*)$ /index.php/$1 [L]". It should not hurt the rest of the wordpress installation but allows for high performance reverse proxying of wordpress installations using mod_cache.

I'm assigning this major severity as the original RewriteRule rule can lead to unwanted content disclosure and can result in wrong content for a URL being delivered.

This bug triggers in mod_cache as soon as proper combinations of HTTP caching headers are sent (Expires, Cache-Control, etc). However, it will not trigger in default apache (read "non-mod_cache") configurations, only when you apply high-performance content caching configurations within apache in combination with mod_rewrite.

Last edited 15 months ago by wasabi_flagg (previous) (diff)

#6 in reply to: ↑ 5 @hurikhan77
15 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

After all this time, I decided that mod_cache is just broken by design. At least it's not made to be used as a front-end cache. We saw similar behavior with 404 errors resulting from this rewrite rule. In the end, we ditched mod_cache and placed Varnish or caching nginx in front of WordPress. When used together with W3 Total Cache plugin, this greatly boosts performance much more than mod_cache could ever do.

Take note, tho, that Varnish is recommended to be used as a frontend for single web application only, and it needs configuration changes specially tailored towards the backend web application - the default configuration has a lot of annoying edge cases. So this won't work well for caching multiple sites in a shared hosting environment. In this case, I'd recommend going the nginx route.

I'm closing this again because I no longer consider it as an issue (as the WP devs also do). I wonder why this was resurrected anyways given it is several years old. Or maybe I just got notified lately due to some other trigger. But this should be closed as wontfix: mod_cache is not compatible in many more than just one way, and this is not just a WordPress issue. If anything, this should be fixed in mod_cache itself.

Replying to wasabi_flagg:

I tried to change

"RewriteRule . /index.php [L]"

into

 "RewriteRule ^(.*)$ /index.php/$1 [L]"

but WordPress gives me "File not found" for every page but the homepage
Apache 2.4.25
Mod_Cache_Disk
Php7-FPM
Wordpress 5.2.2

Last edited 15 months ago by hurikhan77 (previous) (diff)

#7 @SergeyBiryukov
15 months ago

  • Component changed from General to Rewrite Rules
Note: See TracTickets for help on using tickets.