bneradt opened a new issue, #13654: URL: https://github.com/apache/trafficserver/issues/13654
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 and the undersized JIT stack described in #13651, but resource exhaustion remains possible and its handling needs a separate decision. ### Current behavior The [error branch](https://github.com/apache/trafficserver/blob/390bafd7683d14de7faee45129a122557456c092/plugins/regex_remap/regex_remap.cc#L1171) 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: ```text ^/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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
