This request proposes a fundamental shift in how F5 Distributed Cloud (XC) handles configuration inputs. Instead of choosing between a single literal value or a complex Regular Expression, the UI should provide a Unified Matcher capable of handling multiple entries with built-in "Exclude" logic.
The Current Limitation: The "Regex or Redundancy" Trap

Currently, users face a binary choice that hinders scalability:

1. Redundancy: Manually creating 20+ individual rules for 20 different paths/values, leading to configuration bloat.

2. Complexity: Writing a single, monolithic Regular Expression to cover multiple values.

   • The Risk: Regex is difficult to audit, requires specialized knowledge, and is "all-or-nothing"—removing one value requires re-testing the entire string.

Proposed Solution: "Smart List" Input UI

Transform standard input fields into a Generic Matcher Component that supports:

• Multi-Entry Input: A single field that accepts a list of values (e.g., paths, IP ranges, or headers) via bulk paste or tag-style entry.

• Integrated Negation (Exclusion): Within the same UI block, a "Subtract" or "Exclude" section to define exceptions (e.g., Match all these patterns, EXCEPT these specific ones).

• Pattern-Based Logic (No Regex Required): Use simple wildcards (*) that the UI automatically parses, reducing the need for Go-compliant regex for 90% of use cases.

Example scenario below:

Challenge:

The current workflow presents two significant operational challenges:

1. Regex Maintenance: Using regex for exclusions (e.g., matching a directory but excluding a specific sub-path) is error-prone and requires extensive re-validation whenever a single path changes.

2. Route Proliferation: Creating separate routes for 10+ similar paths leads to "Configuration Sprawl," making the Load Balancer object difficult to audit and navigate.

Expectation:
Introduce a "Path Collection" or "Advanced Matcher" UI component within the Route configuration. This should allow:

• Bulk Entry: A text area or list view to add multiple paths (e.g., /path1, /path2) that share the same origin/pool behavior.

• Negation Rules (Exclusions): A built-in "Except" or "Exclude" toggle for specific sub-paths (e.g., Match /cab-booking/* but exclude /cab-booking/cancellation/*).

• Visual Logic: A single-page view where the relationship between matched paths and excluded paths is clear without reading code.

One example from Akamai screen is attached where we can see how simple it is to add multiple paths and perform operation on it , whereas in XC it requires multiple regex to achieve it. And regex makes both day 1 and day 2 operation complex.

akamai_screen.png

Attachments Open full size