WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 4 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: General 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 (4)

#1 @f00f
7 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
7 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
7 years ago

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

#4 in reply to: ↑ 3 @drzraf
4 months 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 ;)

Note: See TracTickets for help on using tickets.