URL escaped paths don't match

[raphael]

Consider the following route:

router.GET("/foo/\\*starToken", handler) // matches /foo/*starToken

And the following client code:

u := URL{Host: "localhost:8080", Scheme: "http", Path: "/foo/*starToken"}
req, _ := http.NewRequest("GET", u.String(), nil)
resp, _ := http.DefaultClient.Do(req)
if resp.StatusCode == 404 {
    fmt.Println("oh noes")
}

Then "oh noes" gets printed. That's because u.String() returns:

"http://localhost:8080/foo/%2AstarToken"

It seems httptreemux is not handling the escape properly. Now it could also be argued that the stdlib is being a bit too generous in its escaping, http://www.rfc-editor.org/rfc/rfc1738.txt states that "*" is OK in URLs but it is what it is...

[dimfeld]

Hmm, interesting. I may fix this by adding both escaped and unescaped versions of the URL to the tree, when applicable. I won't be able to do any work on this until next week some time, but will think about it in the meantime. Thanks for the report!

[raphael]

Yes I was thinking the same (adding both routes to the tree). FWIW the issue doesn't seem to be there for : https://play.golang.org/p/gs1DkJ5Bt0

[dimfeld]

Sorry for the delay. Been really busy with work and also moving interstate. But I haven't forgotten about this. I'll be able to get it done some time this month.

[raphael]

np, thanks for the heads up!

[dimfeld]

I have this implemented, still need to write a couple tests. But I remembered that you can tell httptreemux to use r.URL.Path instead of r.RequestURI by setting router.PathSource = httptreemux.URLPath. That might actually be the better solution since we then don't have to worry about inconsistencies with which characters Go chooses to escape vs. the characters that any particular client escapes. As an example, Go does not encode the : character, as you pointed out, but the Javascript encodeURIComponent function does. What do you think of this?

[raphael]

Thanks! yes that might work. Need to understand better how RequestURI and URL.Path defer...

[dimfeld]

My understanding is that URLs generated by url.Parse have the Path
field unescaped, so the %2A will be converted back to a * and the router
will match on the unescaped path. But let me know if you try this and it
still isn't working for you.

On Sat, Jul 30, 2016 at 7:05 AM, Raphaël Simon notifications@github.com
wrote:

Thanks! yes that might work. Need to understand better how RequestURI and
URL.Path defer...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#32 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABTl1kWwCYxDhAplFxWJ6P4dQfE7zeDvks5qa4RagaJpZM4I-EJQ
.

[raphael]

So I tried that and it won't work for my use case :( I have slashes in my URLs that need to stay escaped for the route to match.

[dimfeld]

Yeah, that is the caveat of using URL.Path. Ok, I'll see about getting the "escape the route" change in this week. :)

[raphael]

Awesome, thank you!

[raphael]

Thank you!