httprouter
httprouter copied to clipboard
julienschmidt
Router should use raw HTTP path for route matching
At the moment, "/param1a%2fparam1b/tail" matches route "head/:param1/:param2/tail" instead of ":param1/tail". There's no way we can have a '/' in a URL param.
I just came here to open this same issue. It seems that %2F is being decoded to / before trying to match a route path. In that way the lib is not supporting a param value (correctly encoded) containing a forward slash.
EDIT: There is a long standing issue of httprouter, see #55 and #209
@weiwei-lin @DiegoZoracKy
As the document mentioned, the named parameters(:name) match anything until the next '/' or the path end.
But catch-all parameter(*name) will match the anything until the end, you should use catch-all parameter instead.
Btw, it doesn't make sence that named parameters should match /, since head/:param1/tail and head/:param1/:param2/tail are conflicting.
you should use catch-all parameter instead.
Unfortunately, that only works if we only have encoded character in the last path component.
For example, there's still no way to match "head/a%2Fb/c%2Fd/tail" to "head/:param1/:param2/tail".
Even more, with the existing routing mechanism, there's no way to distinguish between "head/a%2Fb" and "head/a/b".
since head/:param1/tail and head/:param1/:param2/tail are conflicting
You are right. But my point was that
/param1a%2fparam1b/tailwill match"/:param1/:param2/tail"if that route exist, which is incorrect./param1a%2fparam1b/tailwill not match"/:param1/tail"if that route exist, which is also incorrect.
The whole point of doing URL escaping is because we don't want to treat the encoded characters as special characters. Using decoded path to perform routing defeats the whole purpose of URL escaping.
I just updated #209 if it's helpful to you. I had to use a forked version with this change on a project due to the nature of the urls we had to deal with.
