-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using capture groups in path regexes has unexpected behaviour #143
Comments
Thanks for reporting this! I'll fix the docs to make this clearer. |
Appears to still be broken. I ran my tests against the older version (e444e69) I had in my go vendoring, saw the expected failure, updated to mux's head of master, ran the same tests and got the same failure. |
Did you want to submit a PR updating the docs? I won't have time for a while. |
I'm a little overbooked right now too. No promised but if I get time I'll submit an update. |
I was hit by this issue, but it's possible to workaround with non-capturing groups. #196 contains an update to the documentation. |
document non-capturing groups (closes #143)
Refer to #200 |
I think this is probably just a docs improvement. Unless it's buried somewhere, the docs don't specify that regexes shouldn't be wrapped in a capture group. Doing so causes unexpected behavior when used in any location but the last regex.
Examples:
"/{name:.*}.{ext:([a-zA-Z0-9]+)}"
"/foo.bar"
map[name:foo ext:bar]
"/{name:(.*)}.{ext:[a-zA-Z0-9]+}"
"/foo.bar"
map[name:foo ext:foo]
It would be great if the docs clearly stated that the regexes shouldn't have an enclosing capture group. At the moment it can only be inferred from the examples, which becomes especially confusing when it works some of the time (i.e. when the only capture group is the final regex).
The text was updated successfully, but these errors were encountered: