# Usage Examples¶

Here are some examples for how to set rewrite rules and response headers for particular situations.

## Cache Everything for 2 Minutes¶

<IfModule LiteSpeed>
RewriteEngine On
RewriteRule cacheablefolder/(.*\.php)?$- [E=cache-control:max-age=120] </IfModule>  Note These rules only cache *.php files in the cacheablefolder directory. It is good practice to be specific, and cache only the files that are supposed to be cached. ## Cache Pages With a Certain Signature¶ These two examples demonstrate how LSCache rewrite rules fit into an application's existing rewrite rules. ### Public Cache Example¶ The second part of the ruleset is from the web application. Essentially everything goes through index.php (the web app framework) to process. Note %{ORG_REQ_URI} is a LiteSpeed-specific variable. In this example, it keeps the value of %{REQUEST_URI} prior to the rewrite to index.php. # this part is for public cache. <IfModule LiteSpeed> RewriteEngine On RewriteCond %{REQUEST_METHOD} ^HEAD|GET$
RewriteRule .* - [E=Cache-Control:max-age=300]
</IfModule>

#application orgiginal rewite rules
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php [L]


The first part of the ruleset indicates that LSWS only caches requests if:

• They are HEAD or GET type requests AND
• They don't contain cookiename in the HTTP_COOKIE AND
• %{ORG_REQ_URI} does not start with /administrator/

Also:

• The TTL of the cache is set to 300 seconds (5 minutes).

### Private Cache Example¶

# this part is for private cache, note that HTTP_COOKIE is for loginuser
<IfModule LiteSpeed>
RewriteCond %{REQUEST_METHOD} ^HEAD|GET$RewriteCond %{HTTP_COOKIE} loginuser RewriteCond %{ORG_REQ_URI} !^/index\.php$
# there is no need to exclude admin area. it can be privately cached.
RewriteRule .* - [E=Cache-Control:private]
</IfModule>

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$[NC] RewriteRule (.*) index.php [L]  This ruleset indicates that LSWS only privately caches requests if: • They are HEAD or GET type requests AND • They do contain loginuser in the HTTP_COOKIE AND • %{ORG_REQ_URI} is not /index.php AND • %{ORG_REQ_URI} ends with .php or .html or .htm , etc. Also: • The TTL is set to whatever is the default in the private cache policy ## Cache Mobile View Separately¶ If your web app produces a mobile view that has different HTML than the desktop view, you will want to set up a cache vary based on user agent. In this example, we set the vary value to cache the mobile view separately. We also exclude some folders from cache, and cache everything else for two minutes (120 seconds). <IfModule LiteSpeed> RewriteEngine On CacheDisable public / RewriteCond %{HTTP_USER_AGENT} "iPhone|iPod|BlackBerry|Palm|Mobile|Opera Mini|Fennec|Windows Phone" RewriteRule .* - [E=Cache-Control:vary=ismobile] RewriteCond %{REQUEST_METHOD} ^HEAD|PURGE|GET$
RewriteCond %{ORG_REQ_URI} !/news
RewriteRule .* - [E=Cache-Control:max-age=120]
</IfModule>


Login Vary Cookie conflicts can pop up when you have multiple web applications with LSCache plugins enabled on the same document root, with one app being served from a subdirectory of another (as in www.example.com/ and www.example.com/app2/). This can happen with distinct web applications, or multiple installations of the same app (e.g. two copies of WordPress).

Of particular concern is the _lscache_vary cookie, which is the default used by every LSCache plugin, and indicates the logged-in status of a user. As such, it is in control of what version of a page (logged in or not logged in) is served.

As far as the browser is concerned, both apps are the same website because one app is actually a subdirectory of the other. When the browser visits app2, it will use the cookies for www.example.com/. Even though app2 is an entirely separate application, to the browser it looks simply like a part of app1 because it lives at www.example.com/app2/.

Here's how this situation presents itself: A user logs into app1, and the _lscache_vary cookie is set to indicate that they are logged in. This same user then visits app2 as a non-logged-in user and hits the backend. LSCache caches the non-logged-in request, but the logged-in _lscache_vary cookie is still set. This causes future users logged-in to app2 to get a "cache hit" on this page and be served the non-logged-in version of the page.

To avoid this situation, each application under the same root needs a uniquely-named cookie. Add the following to .htaccess after RewriteBase and before all rules using the [L]:

RewriteRule .? - [E=Cache-Vary:_my_custom_vary]


_my_custom_vary is the new login cookie name that should be used by your plugin.

Last update: July 31, 2020