A regex resource error in regex_remap is logged but does not stop rule evaluation. The plugin continues to later rules, so an exhausted match can produce a successful redirect to a different destination. If no later rule matches, the plugin returns TSREMAP_NO_REMAP.
Bryan Call pointed out this separate behavior while reviewing #13652. That PR fixes the overly low matching-work limit described in #13651. The proposed JIT-stack change was withdrawn from that PR after review; resource exhaustion remains possible and its handling needs a separate decision.
Current behavior
The error branch increments the failure count and logs any negative result other than PCRE2_ERROR_NOMATCH, then continues the loop. It does not distinguish a failed evaluation from a genuine non-match when deciding whether to try the next rule.
The regression test in #13652 demonstrated this with these rules:
^/cms(\?.*)TOKEN(.*)$ https://redirect.example/cms$1TOKEN$2 @status=302
^/cms.*$ https://fallback.example/ @status=307
Before the matching-work fix, /cms?partner=TOKEN&x= followed by 2,000 a characters exhausted the first rule's work limit (-47). ATS then returned the fallback 307 rather than the intended 302. This was verified in an end-to-end AuTest. The limit fix makes that particular input succeed, but does not change the error branch.
Desired behavior
Define and test an explicit policy for match-work, depth, heap, and JIT-stack exhaustion. A matching error should not automatically be treated as a non-match and redirect to an unrelated fallback destination. Returning a visible transaction error is one possible policy; compatibility with configurations that currently rely on fallthrough needs consideration.
The follow-up should cover both a later fallback rule and the case where no later rule matches. The current diagnostic logging should remain useful even if transaction handling changes.
A regex resource error in
regex_remapis logged but does not stop rule evaluation. The plugin continues to later rules, so an exhausted match can produce a successful redirect to a different destination. If no later rule matches, the plugin returnsTSREMAP_NO_REMAP.Bryan Call pointed out this separate behavior while reviewing #13652. That PR fixes the overly low matching-work limit described in #13651. The proposed JIT-stack change was withdrawn from that PR after review; resource exhaustion remains possible and its handling needs a separate decision.
Current behavior
The error branch increments the failure count and logs any negative result other than
PCRE2_ERROR_NOMATCH, then continues the loop. It does not distinguish a failed evaluation from a genuine non-match when deciding whether to try the next rule.The regression test in #13652 demonstrated this with these rules:
Before the matching-work fix,
/cms?partner=TOKEN&x=followed by 2,000acharacters exhausted the first rule's work limit (-47). ATS then returned the fallback 307 rather than the intended 302. This was verified in an end-to-end AuTest. The limit fix makes that particular input succeed, but does not change the error branch.Desired behavior
Define and test an explicit policy for match-work, depth, heap, and JIT-stack exhaustion. A matching error should not automatically be treated as a non-match and redirect to an unrelated fallback destination. Returning a visible transaction error is one possible policy; compatibility with configurations that currently rely on fallthrough needs consideration.
The follow-up should cover both a later fallback rule and the case where no later rule matches. The current diagnostic logging should remain useful even if transaction handling changes.