4.4.2. Rules Engine and Caching
Rules Engine Capabilities:
- Match conditions (URL, headers, query strings, cookies)
- Actions (route override, redirect, header modification)
- Rule priority and chaining
Caching:
| Setting | Purpose |
|---|---|
| Query string caching | How to handle query strings in cache keys |
| Compression | Enable/disable compression for cached content |
| Cache duration | Override origin cache headers |
| Cache behavior | Follow origin headers or override |
Rules run in priority order, and every matching rule runs. This is unlike a routing rule, where the first match wins. A rules engine is a pipeline: an earlier rule can rewrite a header that a later rule then matches on, which is powerful and is also the usual reason a rule set behaves unexpectedly.
Query string handling defines the cache key, and this is the setting that most often causes either a poor hit rate or the wrong content being served. Ignoring query strings means ?id=1 and ?id=2 share one cached object — fast, and wrong for anything personalised. Including them means a tracking parameter appended by a campaign creates a brand-new cache entry for identical content.
💡 First Principle: Caching decisions are really key-design decisions. Ask what makes two requests the same response, and configure the key to match that.
