Class GuardRuleEngine

java.lang.Object
org.frontcache.guard.GuardRuleEngine
public class GuardRuleEngine extends Object
Runs the guard rules for every request, before cache and origin. Rules are evaluated in order, first match wins: 1. built-ins (uri-too-long, bad-request) - always first, they are the structural checks 2. rules from FRONTCACHE_HOME/conf/guard-rules.conf, in file order The rule list is global - there is no per-domain guard-rules.conf (a rule targets a domain with a host~ predicate). Guards run on the request thread for every request, so evaluate() is written to allocate nothing on the common no-match path and to never throw: any unexpected failure is logged and treated as "no match", leaving Frontcache behaving exactly as it does without guards.

  • Field Details

  • Constructor Details

    • GuardRuleEngine

      public GuardRuleEngine(int maxRequestURILength)

  • Method Details

    • reload

      public void reload()
      Re-reads guard-rules.conf. Built-ins are rebuilt too, so a changed front-cache.max-request-uri-length is picked up by the next FrontCacheEngine reload.

    • getRules

      public List<GuardRule> getRules()

    • validate

      public List<String> validate(String content)
      Dry-parses a candidate guard-rules.conf without touching anything live, for the set-config management action. Nothing here mutates state. No rule swap, no ClientIpResolver.reload(), no hit counters reset, no rate-limit buckets bound to the live registry - the parsed rules are thrown away. The allowlist used is the live one, which is correct: it comes from frontcache.properties, not from the file being edited.
      Returns:
      one message per unusable line, "line N: ...", in file order; empty when the whole file parses

    • evaluate

      public GuardOutcome evaluate(RequestContext context)
      Runs the rules for one request. Never throws.
      Returns:
      a terminal outcome (reject/redirect) or CONTINUE, carrying any dry-run rules that matched so the caller can log them