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
Right now, the query params of the incoming request are sorted by key before we try to match against all the registered Regexps and URI objects. This works fine for URIs, because we can sort those query params too, so the user doesn't even know.
For Regexps, though, it seems impossible to figure out what part of the Regexp represents the query params and sort it; so the user has to be aware that their Regexp must be written to match against sorted params. That can be kind of hard sometimes. For example, a registration might look something like:
/example\.com\?[z\d]{2}=1&(opt1=a|opt2=b)$/
To match this URI:
http://example.com?9z=1&opt2=b
But also this URI:
http://example.com?zz=1&opt1=a
So you can see that if we sorted the second URI's params by key, it wouldn't match the Regexp. Instead, the user would have to register a Regexp that matches either order (or do two register_uri calls), which is pretty ugly.
We tried getting around this by calculating all the possible orders of the params and matching them, but that's O(n!) and therefore intractable for even pretty reasonable query params counts.
So the idea is that we could add a new API entirely, and get the query params out of the Regexp. Maybe an additional argument to register_uri with a hash of params that must in the request?
Right now, the query params of the incoming request are sorted by key before we try to match against all the registered Regexps and URI objects. This works fine for URIs, because we can sort those query params too, so the user doesn't even know.
For Regexps, though, it seems impossible to figure out what part of the Regexp represents the query params and sort it; so the user has to be aware that their Regexp must be written to match against sorted params. That can be kind of hard sometimes. For example, a registration might look something like:
To match this URI:
But also this URI:
So you can see that if we sorted the second URI's params by key, it wouldn't match the Regexp. Instead, the user would have to register a Regexp that matches either order (or do two
register_uri
calls), which is pretty ugly.We tried getting around this by calculating all the possible orders of the params and matching them, but that's O(n!) and therefore intractable for even pretty reasonable query params counts.
So the idea is that we could add a new API entirely, and get the query params out of the Regexp. Maybe an additional argument to
register_uri
with a hash of params that must in the request?(Forked from issue #5.)
The text was updated successfully, but these errors were encountered: