fix: match routes on canonical escaped paths

[umputun]

Reported by @paskal. matchHandler chose the route using r.URL.EscapedPath(), the path exactly as the client wrote it, while the director forwards the canonical form. Any character that re-encodes to itself is silently dropped between the routing decision and the forwarded request, so a route regex was evaluated against a string the upstream never sees.

Encoding one character of a protected prefix was enough to miss the protected route, match a wider one, be checked against the wider route's policy, and still arrive at the protected upstream path. It is not specific to %2F: /api/%70rivate/secret works the same way.

Matching now runs on the canonical escaped path, so the routing decision and what the upstream resolves are the same string. Verified against built binaries with a route behind auth: and a wider route into the same namespace:

                              master   branch
/api/private/secret, no creds    401      401
/api/private/secret, creds       200      200
/api/%70rivate/secret            200      401
/api/private%2Fsecret            200      401
/api/private%2fsecret            200      401
/api/remote%2Fsecret             200      403

The %20 and %25 pass-through is byte-identical to master, so the behaviour the existing regression test locks in is untouched.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.