4

I'm using the Mux package from the Golang Gorilla Toolkit for my routes.

Consider the following routes:

m.HandleFunc("/admin/install", installHandler).Methods("GET")
m.HandleFunc("/admin/^((?!install).)*$", adminHandler).Methods("GET")
m.HandleFunc("/admin", adminHandler).Methods("GET")

The problem is with the regex of the middle route - it is not interpreted, so the route will not work!

m.HandleFunc("/admin/{^((?!install).)*$}", adminHandler).Methods("GET")

With the {} curly brackets doesn't work either. It is just ignored, and treated as /admin/

Neither does:

m.HandleFunc("/admin/{_dummy:^((?!install).)*$}", adminHandler).Methods("GET")

In short, what I'm trying to achieve here is to first match the /admin/install route, and that exact route I then want to exclude from the route below, using the regex, but it doesn't work.

Is there some way to use regex with the gorilla mux package?

Dac0d3r
  • 2,176
  • 6
  • 40
  • 76
  • 1
    That's not the syntax for matching a path in gorrila/mux: `[paths] are defined using the format {name} or {name:pattern}`. http://www.gorillatoolkit.org/pkg/mux – JimB Mar 09 '15 at 19:57
  • Heh I edited the post before I saw your comment, but I have of course tested with the following two ways as well: 1) Curly brackets doesn't work with my "exclude" regex. 2) neither does {_dummy: regex} – Dac0d3r Mar 09 '15 at 19:58
  • 1
    that's also not supported syntax for a Go regexp. You don't need to exclude install, as it would be matched by the first route. – JimB Mar 09 '15 at 20:00
  • I have some logic in the admin handler which only works, and only should hit the server, if the user is logged in and the user is set in the request context, so that's my reasoning for wanting to make an exception and exclude the /admin/install route and include all others. :) I know I can code my way around it inside the admin, handler, but it would have been sweet if this would have worked I think :-) – Dac0d3r Mar 09 '15 at 20:03
  • You have selected the wrong answer: `[^install]` is not the same as "not followed by the word install". – VonC Mar 23 '15 at 22:27
  • No but it does solve the problem, by excluding 'install' from the url, which is basically what I requested. The problem before was that /admin/install would also match the /admin/{_dummy:.*} (wildcard routes prefixed by /admin/), which was not the desired behavior. This was what I was trying to solve using negative lookahead, but excluding 'install', does give the desired result as well. [link](http://regexone.com/lesson/4) – Dac0d3r Mar 24 '15 at 00:01

2 Answers2

5

It is actually possible to do this:

m.HandleFunc(`/{_dummy:admin\/([^install]*).*}`, adminHandler).Methods("GET")

Edit:

As my answer to VonC's comment above, here a sample go app: https://play.golang.org/p/nYWNADK7Sr

Run it on your local pc. Try the following routes:

http://localhost:8080/admin/ - (returns "adminHandler")
http://localhost:8080/admin/something - (returns "adminHandler")
http://localhost:8080/admin/install - (returns "installHandler")

So yes VonC, it does solve the specific problem:

"to first match the /admin/install route, and that exact route I then want to exclude from the route below"

But it is correct that it doesn't mean "not followed by the word, install" - this is just an alternative approach which is possible within the bounds of the re2 syntax. To simply "ignore" or exclude the word install, if it happens to show up in the url.

  • It does work (+1). I was a bit confused considering `[^instal]` (you shouldn't need the second `l` here) is a negated character class, is it not? (http://www.regular-expressions.info/charclass.html). – VonC Mar 24 '15 at 07:02
1

It doesn't work because golang regexp follows the re2 syntax, which doesn't support lookahead or lookbehind.

You might need to define an handler for /admin/install first.
Then all others /admin/xxx would be for other routes (ie not /admin/install)

Actually, the OP SK84 adds in the comments:

Even if admin/install is defined first, /admin/ will also be executed. That's what I wanted to avoid.

I guess I need to code around it inside the admin handler then - easy, but not as pretty as this would have been if it had worked.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I feared it would be something like that. That sucks! :-) I guess I need to code around it inside the admin handler then - easy, but not as pretty as this would have been if it had worked. Thanks! Btw... problem with your proposed solution is that even if admin/install is defined first, /admin/ will also be executed. That's what I wanted to avoid. – Dac0d3r Mar 09 '15 at 20:04