Issues using mod_rewrite / mod_cache together (apache)

[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.

[f00f]

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

[nacin]

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.

[drzraf]

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 ;)

[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

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.

[hurikhan77]

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