Closed chilic closed 4 months ago
@chilic I would assume most users want the decoded param value. What's the use-case for the raw value?
Unless I'm missing something, Go 1.22 behaves the same way (automatically decoding the values), see https://go.dev/play/p/rlvkKwpgs_I for example.
@danielgtaylor that is interesting. The use case is to pass parameters with symbols that should be encoded, like HEX value or encoded URL. In Go 1.22 routing works correctly. Example: https://go.dev/play/p/Pv0xuSEKPth
But the flow uses decoded value to slit URL parts:
urlSegments := strings.Split(r.URL.Path, "/")
Which is return 404 error because URL became /demo/a/b/c
instead of /demo/a%2Fb%2Fc
. I mean it's okay to encode param, but it's a mistake to use encoded param to build routing.
P.S. chi example: https://go.dev/play/p/W3mc2lHq2ez (200 code) flow example: https://go.dev/play/p/rYwsgOX58by (404 code)
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 92.65%. Comparing base (
dcfa3e9
) to head (32f0c2d
). Report is 3 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@chilic so sorry I misunderstood what this was about! You are right, the routing is incorrect! However, when getting a path param value it should be decoded rather than in its raw encoded state, so I've added a commit for that to ensure param values are decoded before storing them. Let me know what you think and I can merge it in if everything looks okay!
I agree with you. Better to keep the behavior the same as the HTTP
package. Thank you!
Problem: The current implementation does not allow to use of encoded named parameters like:
/path/:param
-/path-params/a%3A%2F%2Fb%2Fc
Which is fully legal by RFC 3986
Solution: Use EscapedPath() instead of direct access to a
u.Path
Details: https://pkg.go.dev/net/url#URL
PR into the original package: https://github.com/alexedwards/flow/pull/11