Cache Engine Enhancements
LiteSpeed Web Server v6.0 is here! Among other cutting edge features, this update introduces a few enhancements to the LSCache Engine. These changes, including POST response caching, and improved PURGE/REFRESH by URL, were designed to provide greater flexibility in managing your customized web application caches.
POST Response Caching
Previously, only GET responses were cacheable, but as of LSWS v6.0, you will be able to cache POST responses as well.
To take advantage of this feature, two things need to happen:
- POST caching must be enabled at the server level: In the WebAdmin Console, navigate to Cache Policy Configuration and set Enable POST Cache to
Yes. - The response header must include
X-LiteSpeed-Cache-Control, which is used to indicate that the response is cacheable.
Cache Tags via Rewrite Rules
Cache tags are the mechanism used by LiteSpeed’s cache engine to group content together and enable intelligent purging of related cache objects. Traditionally, tags have been assigned via the X-LiteSpeed-Tag response header, but v6.0 will allow you to do it with rewrite rules.
Rewrite rules can set cache tags for any cached response that hasn’t already been tagged, like so:
RewriteRule /cached/url - [E=Cache-Tag:exampletag]
If tags have already been assigned by response header, the rewrite rule will be ignored.
To assign multiple tags to the cached response, the tags must be within quotes:
RewriteRule /cached/url - [E=”Cache-Tag:tag1,tag2”]
Enhanced Purge/Refresh by URL
LSCache’s earlier purge-by-URL feature only purged a single matching cache object. If there were varying copies of the URL, like in the case of mobile and desktop views, only one of those copies would be purged.
In v6.0, the request URL will be treated as a special cache tag. It will always purge all varying copies of the same URL, and may also be used to purge cache objects for the same URL with different query strings.
The methods for purging by URL will not change. You may continue to use the PURGE or REFRESH request methods, or the X-LiteSpeed-Purge response header. Additionally, the lsws/admin/misc/purge_cache_by_url script is still available to send a PURGE/REFRESH request, but the client IP must be trusted.
Examples Using the X-LiteSpeed-Purge Response Header
Purge /url/to/be/purged, including varying copies if any exist:
X-LiteSpeed-Purge: /url/to/be/purged
Purge /url/to/be/purged, including any copies with query strings (regardless of what that string may be):
X-LiteSpeed-Purge: /url/to/be/purged?*
This won’t work with wildcards or Regex patterns. The only acceptable use of * when purging by URL, is to signify “any query string” as in the example above. In other words, do not use /url/prefix* to purge all URLs starting with /url/prefix. If you must purge a group of URLs in this manner, you should use an explicit cache tag. In other words, assign all relevant URLs starting with /url/prefix a particular tag, and PURGE/REFRESH that tag.
Stale purge /url/to/be/purged, including any copies with query strings:
X-LiteSpeed-Purge: stale, /url/to/be/purged?*
Stale purge is equivalent to a REFRESH request type. It enables an out-of-date cache object to be served to users while a fresh copy of the page is in the process of being cached. This is useful on busy sites, where there could be hundreds of requests for a page before the caching process has completed. In these cases, it may be better to serve out-of-date content from cache than to attempt to fill such a volume of requests with uncached content.
Conclusion
With POST response caching, the ability to add rewrite-rule-based cache tags, and improvements to purge-by-URL, LSCache is upping its game yet again. A tradition of excellence in web app acceleration continues!
Get a trial license and try LiteSpeed Web Server v6.0 today!
Comments