2026-09-02 · 6 min read · Rahul Chitturi
- url
- routing
- debugging
A path parameter containing %2F can work in a local framework and fail behind a CDN, proxy, or application server. One component may preserve the encoded slash, another may decode it into a path separator, and a third may reject it before routing.
Double encoding can appear to fix one hop while creating an ambiguous path or access-control problem at the next. The correct behavior must be defined across the complete request chain.
Record every path representation
Send a harmless identifier and capture the client URL, CDN or proxy request target, application server raw path, framework route parameter, and final decoded value. Note exactly which layer decodes each percent sequence.
- Distinguish path segments from query parameter values
- Compare uppercase and lowercase percent escapes
- Check encoded slashes, backslashes, dots, and percent signs
- Review proxy normalization and rejected-request logs
Choose an unambiguous identifier transport
Prefer path-safe opaque identifiers or move values containing separators into a query parameter or request body when the API design permits it. Base64url can represent binary identifiers without slash characters, but its profile and padding rules must be explicit.
Do not globally allow encoded separators to solve one route. Normalize once, validate the canonical form, and apply authorization to the same path representation used for resource lookup.
A Flashman workflow
Use the URL tool to inspect component encoding, diff to compare representations at each hop, Base64 for synthetic identifier variants, and JSON formatter for gateway or framework event samples.
Test direct and proxied requests, single and double encoding, traversal-like segments, redirects, cache keys, signatures, route generation, and the production server stack.