HAProxy warns on any pattern whose first character is "(", because it
cannot distinguish an intended regex from a fetch-argument list with a
stray space:
parsing acl 'wp_admin_asset' : matching 'path_reg' for pattern
'(^|/)wp-admin/...' is likely a mistake and probably not what you want.
"--" is HAProxy's documented end-of-flags marker and is the remedy the
warning itself names. Cosmetic to matching, but not to operations: left
unsilenced it fires on every config load and every reload on every host,
which trains operators to skim past warnings and gives a real one
somewhere to hide.
Matching semantics are unchanged, verified rather than assumed. Both
forms were run side by side as two frontends under real HAProxy
3.0.11-1+deb13u3 and gave identical verdicts on all 8 vectors:
/wp-admin/css/login.min.css MATCH / MATCH
/wp-admin/js/user-profile.min.js MATCH / MATCH
/wp-admin/images/x.png MATCH / MATCH
/wp-admin/css/sub/deep.css MATCH / MATCH
/blog/wp-admin/css/a.css MATCH / MATCH
/wp-admin/css/x.php NOMATCH / NOMATCH
/wp-admin/plugins.php NOMATCH / NOMATCH
/some--path/file.css NOMATCH / NOMATCH
The last vector is the one that matters: it proves HAProxy consumed "--"
as end-of-flags rather than adopting it as the pattern. Had it done the
latter, the ACL would have matched paths containing "--" and stopped
matching css/js -- gating every login page's own stylesheets while the
page itself still returned 200.
wp_admin_path needs no "--" only because its "-i" flag already occupies
the flag slot; it is not otherwise special.
Adds a regression test asserting both the "--" and the pattern it
guards, so this cannot pass by the pattern having been changed. Verified
to fail when the "--" is removed.
shadowdao
465253c640