PAC shExpMatch Uses Wildcards, Not Regular Expressions

A proxy rule can look correct yet never match because shExpMatch and JavaScript regular expressions use different pattern languages.

In PAC, shExpMatch uses shell-style wildcards. For subdomains of example.com:

if (shExpMatch(host, "*.example.com")) {
    return "PROXY proxy.example:8080";
}

Use the policy's selected HTTP endpoints in these return values; the HTTP proxy list supplies candidates for permitted public routes. The asterisk matches a sequence of characters. It is not a regular-expression repetition operator, so a regex-looking .*example.com changes the meaning.

Include the exact parent name explicitly when it belongs in the policy:

if (host === "example.com" || shExpMatch(host, "*.example.com")) {
    return "PROXY proxy.example:8080";
}

Using *example.com instead would also accept names ending in those letters without a separating dot. That broadens the set beyond the intended domain boundary.

The portable PAC wildcard baseline includes * and ?; character classes vary by implementation. A JavaScript regex instead uses test() and its own anchoring and escaping rules.

Match the intended input. host is a hostname, while url includes a scheme and may have been sanitized. A domain rule should not accidentally depend on a path the browser never supplies.

Tënë sô zo