julienschmidt / httprouter

A high performance HTTP request router that scales well
https://pkg.go.dev/github.com/julienschmidt/httprouter
BSD 3-Clause "New" or "Revised" License
16.65k stars 1.47k forks source link

Router should use raw HTTP path for route matching #284

Open weiwei-lin opened 5 years ago

weiwei-lin commented 5 years ago

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.

DiegoZoracKy commented 5 years ago

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.

razonyang commented 4 years ago

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.

weiwei-lin commented 3 years ago

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

  1. /param1a%2fparam1b/tail will match "/:param1/:param2/tail" if that route exist, which is incorrect.
  2. /param1a%2fparam1b/tail will 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.

halorium commented 3 years ago

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.

darrenparkinson commented 2 years ago

Also here looking for this. Any chance this might be added?