You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 22, 2022. It is now read-only.
It's not your fault, certainly. I had a nasty feeling as I saw this, and I think it's come down to the fix for this: #173 breaking things here. We're re-encoding the path and query, but that's causing 1,2 to become 1%2C2, which is then getting matched as a single value.
I'm going to need to think about this carefully. There's a (very, very annoying) assumption baked in to OWIN that the consumer would only want a percent-decoded path. I'll need to think about the right way to strike a balance here while still making something RFC compliant. I'm sure it's possible, but it's going to be trickier.
The answer to that is "potentially"! Paths are matched in precedence order. There would be no way to distinguish, for example, between a listofstuff with one item, and a singlearg. So if the match with listofstuff was declared first, and higher precedence, you would never hit singlearg, as you would already have matched. If you reversed them, you would potentially still see different things, as singlearg would now match listofstuff in the single item case!
How problematic that is probably depends on your specific use case.
I tried to follow the example here: http://docs.freya.io/en/latest/router/examples.html#lists to have a list of parameters:
Executing:
the value becomes:
Any pointers to what I am doing wrong?
The text was updated successfully, but these errors were encountered: