Open haitch opened 3 months ago
After dig into the code, I think the key is func (c CurlyRouter) regularMatchesPathToken(routeToken, colon, requestToken)
, where it try to match a requestToken xxxhello
to a routeToken {h:(?i)hello}
.
in my example setup, c.regularMatchesPathToken("{h:(?i)hello}", 3, "xxxhello")
was invoked. inside the function, curly bracket was removed, then, it's matching "(?i)hello" to "xxxhello", it did match hello, despect the prefix xxx.
helloRegex := regexp.MustCompile("(?i)hello")
matches := helloRegex.FindStringSubmatch("xxxhello")
log.Println(matches) // []string{"hello"}
did find a workaround by using more strict regex {h:(?i)^hello$}
, the ^$ would ensure whole token match.
send PR with example on how to handle this issue safely #546
thank you for reporting this issue and investigating the problem. I will have a look at the PR.
thanks for merging the example PR, hopefully that will help someone.
As a library, I think we want to prevent caller from make mistakes and cause misroute, can we consider have regex to match the whole routeToken with next minor release where you can introduce break changes.
to accept case-insensitive paths, we use
{h:(?i)hello}
, to accept /HELLO, /hello, /Hello.but with this approach, it also triggered a bug where /xxxHello, /yyyHello also got accepted.