rfcPath

[szuecs]

Describe the bug

@arpitjain099 reported

The -rfc-patch-path flag double-encodes: a client sending %2F results in the backend receiving %252F, defeating the flag's stated purpose. A correctness bug with a security-adjacent motivation.

with suggested fix

Fix the double-encoding in the rfc-patch-path handling.

and note

Important negative: the normalization-divergence class is ABSENT here (recording it because the negative is useful). routing/matcher.go line 483 matches on httppath.Clean(r.URL.Path), the most normalized form, so every crafted variant lands on the MORE protected route. A 19-row executed probe table (//admin, /./admin, /pub/../admin, /%2e%2e/admin, /%2fadmin, /pub%2f..%2fadmin, /%61dmin, /admin/.) all returned 403 on the protected route. Skipper's approach here is the correct design.

To Reproduce

1. start skipper with -rfc-patch-path * -> "http://127.0.0.1:9002" and a backend like nc -l 9002
2. curl -v "http://127.0.0.1:9090/f%2Foo
3. the backend sees path /f%252Foo but should see /f%2Foo

Expected behavior****Observed behavior

I don't know since it never worked different. We have to understand what the feature is about.