WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years 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: 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 (3)

comment:1 @f00f5 years ago

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

comment:2 @nacin5 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.

comment:3 @nacin5 years ago

  • Milestone Unassigned deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.