PR for middleware support #293

nadiamoe · 2017-09-08T16:46:19Z

Hello there,

I've been using gorilla/mux for a while on an internal project at my organization, and due to some requirements, I ended up forking the project and adding some extra features, such as internal support for middleware.

Yes, I am aware that negroni is a thing, and that it also provides this functionality. However, there are a few key things you can't do just chaining mux after your middleware:

Acting only if a route match is found: Waiting to see if a route actually matches before acting allows for more flexibility and coherent design. For example, an authentication middleware can happily return 403 if the required credentials are not supplied, and at the same time a normal 404 will be returned by mux if the route does not exist. This option does not exist if you need to process authentication headers before the request is matched.
Adding middleware for subrouters is simpler if it is embed inside mux.
It is more efficient. If your site receives heavy traffic and your middleware performs heavy tasks, you'll appreciate this kind of saving.

After pondering a bit, I decided that this simple addon was worth implementing, so I did.

As a middleware needs to be able to stop the handlers chain, I implemented it using a slightly modified http.Handler interface:

type Middleware interface {
	ServeHTTP(http.ResponseWriter, *http.Request) (http.ResponseWriter, *http.Request)
}

type MiddlewareFunc func(http.ResponseWriter, *http.Request) (http.ResponseWriter, *http.Request)

If the middleware implementations return nil as either http.ResponseWriter or *http.Request the chain is stopped. Also, http.ResponseWriter and *http.Request can be hijacked if the middleware wants to. This is an approach slightly different to negroni's, where a third parameter of *http.HandlerFunc is added. I thought this way were better as it simplifies greatly building and iterating the middleware chain. Also, I don't like recursion. Of course, wrapper functions which receive http.Handler and http.HandlerFunc exists, so standard handlers can be chained too.

I'm not sure if you think this feature is kind of out-of scope. But if you don't, I'll happily open a PR and discuss any modifications or style changes you'd want to be done.

The text was updated successfully, but these errors were encountered:

abdullah2993 · 2017-09-11T14:36:43Z

I second this proposal. it will actually be very useful...I'm currently working on an authentication middleware so I wanted to add the ability to allow certain routes without authentication but can't because mux.CurrentRoute returns nil if not called from the the handler it self
@roobre IMO you are making it more complex then it has to be. something like this is fine IMO

abdullah2993 · 2017-09-11T15:25:51Z

Can I send a pull request with something like this
Diff: master...Abdullah2993:master
commit: https://github.com/Abdullah2993/mux/commit/5297e1495880923aed73b18911ad4ce6f4e27472

elithrar · 2017-09-11T16:08:43Z

Let me think on the design. Custom middleware interfaces can be tricky and isolate mux. I'd want to see how something like Chi solves this use-case first.

…

On Mon, Sep 11, 2017 at 8:25 AM Abdullah Saleem ***@***.***> wrote: Can I send a pull request with something like this master...Abdullah2993:master <master...Abdullah2993:master> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcKBluOGYU55F4pq5dqp9y-Rq4JT_ks5shVEAgaJpZM4PRbdT> .

nadiamoe · 2017-09-11T16:12:01Z

My fork actually looks like this:

master...roobre:middleware

As I said, I feel that returning the responseWriter and request seems better (to me at least) than adding a third parameter like Negroni does. Other options are, of course, open to discussion. However, please take into account that middleware writers would value the ability to hijack these two objects, so a modification to the http.Handler interface is required.

elithrar · 2017-09-11T16:16:24Z

What does func (http.Handler) http.Handler) not solve here, as the "defacto" middleware interface? (I may be missing something)

…

On Mon, Sep 11, 2017 at 9:12 AM Roberto Santalla ***@***.***> wrote: My fork actually looks like this: master...roobre:middleware <master...roobre:middleware> As I said, I feel that returning the responseWriter and request seems better (to me at least) than adding a third parameter like Negroni does. Other options are, of course, open to discussion. However, please take into account that middleware writers would value the ability to hijack these two objects, so a modification to the http.Handler interface is required. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcAqVzLP7FFVRlZ4uS5jzekfbKmqGks5shVvUgaJpZM4PRbdT> .

nadiamoe · 2017-09-11T16:22:15Z

Also, http.ResponseWriter and *http.Request can be hijacked if the middleware wants to.

Basically your middleware might want to create a new Request or ResponseWriter, and pass them down to the rest of the chain. Think about returning Request.WithContext(), for example. Or maybe creating a custom ResponseWriter implementation.

abdullah2993 · 2017-09-11T19:12:26Z

Basically your middleware might want to create a new Request or ResponseWriter, and pass them down to the rest of the chain. Think about returning Request.WithContext(), for example. Or maybe creating a custom ResponseWriter implementation.

@roobre this can be done with the classical func(http.Handler)http.Handler

nadiamoe · 2017-09-12T16:11:42Z

Now it's me who is probably missing something. How can you create a middleware chain using that interface?

Which http.Handler is passed and what meaning have the returned http.Handler? The purpose of middleware is to operate on the ResponseWriter and Request objects, not on handlers themselves.

elithrar · 2017-09-12T16:55:09Z

You create closures - which is a fairly common way for writing middleware, and makes it portable across any sane library - net/http, gorilla/mux, chi, etc - as it's just http.Handler func MyMiddleware(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // do things }) } Then you can wrap routers or routes - e.g. r := mux.NewRouter() // Some routes go here http.ListenAndServe("localhost:8000", MyMiddleware(r)) Further reading: - https://justinas.org/writing-http-middleware-in-go/

…

On Tue, Sep 12, 2017 at 9:11 AM Roberto Santalla ***@***.***> wrote: Now it's me who is probably missing something. How can you create a middleware chain using that interface? Which http.Handler is passed and what meaning have the returned http.Handler? The purpose of middleware is to operate on the ResponseWriter and Request objects, not on handlers themselves. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcN5BUBktowizhez1xZO7aTuHi7JUks5shq1AgaJpZM4PRbdT> .

nadiamoe · 2017-09-12T16:58:56Z

Thanks for the info :D

It certainly looks good, I'll take a look at it and change the implementation if no functionality is lost.

elithrar · 2017-09-12T17:03:30Z

We won't have to change mux to support this :)

…

On Tue, Sep 12, 2017 at 9:59 AM Roberto Santalla ***@***.***> wrote: Thanks for the info :D It certainly looks good, I'll take a look at it and change the implementation if no functionality is lost. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcJ3R1QtkwVkpuevt2lUXnW2ug63aks5shrhYgaJpZM4PRbdT> .

nadiamoe · 2017-09-12T19:12:02Z

Then that is not the same approach I'm proposing here. There are plenty of tools which can be used to chain middleware before (and after, I guess) mux, but they get executed wether there is a route match or not. The point of adding middleware support inside mux was to circunvent this limitation, allowing middlewares to perform expensive tasks only if the endpoint is correct, or modifying the http status code only if a route is found (particularly useful for authentication middlewares).

elithrar · 2017-09-19T12:59:46Z

Can you share a design proposal for this? Take a look at how other routers are doing this, as well as the previous PRs/Issues raised here for background.

nadiamoe · 2017-09-19T16:10:38Z

I've looked at Negroni and Martini, each having his own approach. I'll look at a couple more and add a few drawings to explain my point better. I'm not sure when I'll be able to do this, this is being a tough week at work. Stay tuned :D

nadiamoe · 2017-09-28T12:19:12Z

Key differences bewteen external and embedded middleware

Hello again. I finally have some time to explain this with more detail. I've (hand-)drawn a diagram to better illustrate the difference between the external middleware approach, which is what you are mentioning, and mine:

As i've said, middleware embedded in mux is evaluated only if a route matches. This saves processing time for non-existing routes, and allows writing of coherent authentication middleware: It will return 404 if no route is found, and 403 if a route matches but the middleware doesn't like it).

Regarding the `Middleware` and `MiddlewareFunc` interfaces

If we look at how urfave/negroni implements middlewares, we see:

HandlerFunc func(rw http.ResponseWriter, r *http.Request, next http.HandlerFunc)

This final next parameter allows middlewares to do two important things:

Stop the Handler chain, and abort the request if they don't call next(rw, r) (pressumably writing an error to rw)
Call the next Handler with new, modified, or tweaked ResponseWriter and Request.

I've chosen to keep both functionalities, so a modified http.Handler which returns its own ResponseWriter and Request. This approach allows the same a flexibility as the third next parameter, but I personally found it more elegant.

I hope this will help to clarify my point, and why I find this useful.

PS: I know there are more ways to do this. In fact, our project does have an authentication middleware implemented with the default mux, which works by creating a new middleware object per route, and wrapping the route handler inside a closure. This is ugly, performs really bad, and has multiple race conditions. So this is why I'm trying to found an alternative.

elithrar · 2017-09-28T12:28:53Z

@roobre Thanks for describing the design in detail. I'll make time to review today/tomorrow and we can decide about moving ahead.

nadiamoe · 2017-09-28T14:21:05Z

Sure!

Also please note that the particular signatures and implementation are open to discussion. The key feature I'm trying to get with this is putting middleware after a match is found, and before the handler is called.

elithrar · 2017-09-28T16:09:02Z

That part [the ordering of matching vs. middleware] makes sense to me!

…

On Thu, Sep 28, 2017 at 7:21 AM Roberto Santalla ***@***.***> wrote: Sure! Also please note that the particular signatures and implementation are open to discussion. The key feature I'm trying to get with this is putting middleware after a match is found, and before the handler is called. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcO7udp_ul9Oy4DdBw7soGstOZmghks5sm6tSgaJpZM4PRbdT> .

abdullah2993 · 2017-09-28T16:23:33Z

@elithrar thats the whole point, the ability to get current route on the Request object is what is desired in the middleware especially with middlewares that deals with auth. With conventional middlewares a call to mux.CurrentRoute returns nil because the context is set after matching and the middlewares are executed before matching the route.
But IMO its much better to use the classic func(http.Handler) http.Handler for this as demonstrated in master...Abdullah2993:master

nadiamoe · 2017-09-28T19:28:08Z

I'll do some experiments tomorrow and think about how could this be implemented using func(http.Handler) http.Handler. I'm concerned about how we could define an interface with this signature, as often middlewares are complex enough to be full objects and not just functions.

abdullah2993 · 2017-09-28T20:45:18Z

@roobre it is actually much simpler then you think...take a look at this all the middlewares use this pattern and it is actually quite simple and elegant

here is a sample of it working

package main

import (
	"fmt"
	"log"
	"net/http"

	"github.com/abdullah2993/mux"
)

type routeLogger struct {
	logger *log.Logger
	next   http.Handler
}

func (rl *routeLogger) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	mr := mux.CurrentRoute(r)
	if mr != nil {
		if rl.logger != nil {
			rl.logger.Printf("[%s] %s", mr.GetName(), r.URL)
		} else {
			log.Printf("[%s] %s", mr.GetName(), r.URL)
		}
	}
	rl.next.ServeHTTP(w, r)
}

//RouteLogger creates a new route logging middleware which logs to the logger if the
//logger is nil then logs to the stdLogger
func RouteLogger(l *log.Logger) func(http.Handler) http.Handler {
	return func(h http.Handler) http.Handler {
		return &routeLogger{logger: l, next: h}
	}
}

func main() {
	r := mux.NewRouter()
	r.HandleFunc("/", index).Name("Index")

	mw := RouteLogger(nil)

	r.AddMiddleware(mw)

	http.ListenAndServe(":8081", r)
}

func index(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "Hello World")
}

nadiamoe · 2017-09-29T08:29:41Z

Correct me if I'm wrong, but doesn't this method imply the creation of a new routeLogger for each HTTP request? I find that a bit suboptimal.

nadiamoe · 2017-09-29T09:13:55Z

Ok, I have migrated implementation to the proposed func(http.Handler) http.Handler function. I've also added an interface (Middleware) which can be used to write complex middlewares without a malloc hell. MiddlewareFunc implements Middleware so it's pretty straightforward.

Here's an example implementation

package main

import (
	"log"
	"net/http"
	"roob.re/gorilla-mux"
)

func main() {
	myMux := mux.NewRouter()
	myMux.AddMiddlewareFunc(simpleMw)

	mw := &myMw{}
	myMux.AddMiddleware(mw)

	myMux.HandleFunc("/", func(writer http.ResponseWriter, request *http.Request) {
		writer.Write([]byte("Handled"))
	})

	http.ListenAndServe("0.0.0.0:8080", myMux)
}

// Simple middleware function
func simpleMw(h http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		log.Println("Yee-haw")
		h.ServeHTTP(w, r)
	})
}

// Complex middleware object
type myMw struct {
	logger *log.Logger
}

func (mw *myMw) theRealThing(uri string) {
	if mw.logger != nil {
		mw.logger.Println(uri)
	} else {
		log.Println(uri)
	}
}

func (mw *myMw) Middleware(handler http.Handler) http.Handler {
	return http.HandlerFunc(func (rw http.ResponseWriter, r *http.Request) {
		mw.theRealThing(r.RequestURI)
		handler.ServeHTTP(rw, r)
	})
}

However, due to how the middleware chain is parsed, middlewares are executed in reverse order. Using for len instead of for range would solve this, but I'd like to hear your opinion on that.

abdullah2993 · 2017-09-29T11:23:22Z

@roobre you are right about the routeLogger being created for each request which is a problem.
as for your implementation can the for range that handles the middlewares moved on to the Router ( Here )?

elithrar · 2017-09-29T11:35:38Z

I would make the order apply in the order that myMux.AddMiddleware(mw) was called, which aligns with route definition (routes defined first take precedence).

…

On Fri, Sep 29, 2017 at 4:23 AM Abdullah Saleem ***@***.***> wrote: @roobre <https://github.com/roobre> you are right about the routeLogger being created for each request which is a problem. as for your implementation can the for range that handles the middlewares can be moved on to the Router ( Here <https://github.com/gorilla/mux/blob/3f19343c7d9ce75569b952758bd236af94956061/mux.go#L245> )? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcA0bWicOblNOMY2Y913rvvfNq-wKks5snNMrgaJpZM4PRbdT> .

nadiamoe · 2017-09-29T21:17:13Z

@elithrar Yes, I find it more appropiate and intuitive. I'll change it the next time I'll put my hands on the code.

@abdullah2993 That would require duplicating the code, for both Router.Handle() and Router.HandleFunc(). What are the benefits of moving it there, if I may ask? Moving the load of iterating over the list away from the HTTP request? I guess there could be a performance gain, but I'm not sure if it would be worth the cringe of having the same code written on two places.

abdullah2993 · 2017-09-30T16:14:50Z

@roobre besides performance gain...it will allow us to apply incremental middlewares i.e the middlewares will only be applied to the routes that are registered after regirstering that middleware...for example in case of some auth middleware you can register allowed path before registering the middleware hence some routes will be executed with middleware and some won't be. In the current situation all the registerd middlewares are applied to all the routes...

nadiamoe · 2017-09-30T16:24:15Z

@abdullah2993 I was planning to circunvent that using subrouters, which I find prettier. Otherwise, if you wanted to add the same auth middleware for 10 routes, you'll end up with 10 different instances of it.

abdullah2993 · 2017-09-30T19:58:27Z

@roobre subrouters can be used to achieve the same thing but this will allow an elegant alternative and will come in handy, not to mention the negligible performance gain.
PS: You don't need 10 instances for 10 routes...you only need 1 instance provided that the routes are registered after registering the middleware...also i don't see this cluttering the code after all its only 3 lines of code, which if needed can be refactored in to a function

elithrar · 2017-09-30T20:00:54Z

@abdullah2993 Can you show a simple example of the benefits of your approach from an user API perspective?

Right now, @roobre's approach—scoping to (sub-)routers makes sense to me, and aligns with other libraries like chi.

abdullah2993 · 2017-09-30T21:43:05Z

@elithrar sure as soon as I get my hands on the computer. This approach will allow not keep you from scoping to sub-routers, if you want to you can but if you don't want to then you can get away with it

nadiamoe · 2017-10-02T13:19:28Z

@abdullah2993 Another problem of moving middleware handling to the route is that becomes difficult to add a middleware to the whole router. Either the user copypastes the whole .AddMiddleware(mw) thing for every route, or they need to use NewRoute().AddMiddleware().Subrouter(), which seems really ugly to me.

We could also allow both Route and Router middlewares, where routes would have their own middlewares []Middleware and AddMiddleware(). However, I find this too complex and maybe confusing (could easily lead to wrong setups where the same middleware is executed twice).

My personal opinion is that middlewares should belong to a router, and not to a route. It just seems more coherent that way. In the end, if you have a middleware that you need to apply to only one or two routes, it makes more sense for that code to be in the route handler instead.

abdullah2993 · 2017-10-02T14:06:03Z

@elithrar @roobre

package main

import (
	"fmt"
	"net/http"

	m "github.com/abdullah2993/mux"
	// m "github.com/abdullah2993/mux1"
)

func main() {
	r := m.NewRouter()

	r.AddMiddleware(mw("1"))
	r.Handle("/", dummyHandler("Index"))

	r.AddMiddleware(mw("2"))
	r.Handle("/login", dummyHandler("Login"))
	r.Handle("/user", dummyHandler("User"))

	r.AddMiddleware(mw("3"))
	r.Handle("/about", dummyHandler("About"))

	fmt.Printf("------------\n")
	http.ListenAndServe(":8080", r)

}

func mw(name string) func(h http.Handler) http.Handler {
	return func(h http.Handler) http.Handler {
		fmt.Printf("Evaluating Middleware %s\n", name)
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			fmt.Printf("[Middleware: %s]: %s\n", name, r.URL)
			h.ServeHTTP(w, r)
		})
	}
}

func dummyHandler(name string) http.Handler {
	fmt.Printf("Adding Handler for %s\n", name)
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, name)
	})
}

Output with first approach:

Adding Handler for Index
Adding Handler for Login
Adding Handler for User
Adding Handler for About
------------
Evaluating Middleware 1
Evaluating Middleware 2
Evaluating Middleware 3
[Middleware: 3]: /
[Middleware: 2]: /
[Middleware: 1]: /
Evaluating Middleware 1
Evaluating Middleware 2
Evaluating Middleware 3
[Middleware: 3]: /login
[Middleware: 2]: /login
[Middleware: 1]: /login
Evaluating Middleware 1
Evaluating Middleware 2
Evaluating Middleware 3
[Middleware: 3]: /user
[Middleware: 2]: /user
[Middleware: 1]: /user
Evaluating Middleware 1
Evaluating Middleware 2
Evaluating Middleware 3
[Middleware: 3]: /about
[Middleware: 2]: /about
[Middleware: 1]: /about

Output with 2nd approach:

Adding Handler for Index
Evaluating Middleware 1
Adding Handler for Login
Evaluating Middleware 1
Evaluating Middleware 2
Adding Handler for User
Evaluating Middleware 1
Evaluating Middleware 2
Adding Handler for About
Evaluating Middleware 1
Evaluating Middleware 2
Evaluating Middleware 3
------------
[Middleware: 1]: /
[Middleware: 2]: /login
[Middleware: 1]: /login
[Middleware: 2]: /user
[Middleware: 1]: /user
[Middleware: 3]: /about
[Middleware: 2]: /about
[Middleware: 1]: /about

which can also allow us to have an api like this

package main

import (
	"fmt"
	"net/http"
	// m "github.com/abdullah2993/mux"
	// m "github.com/abdullah2993/mux1"
	m "github.com/abdullah2993/mux2"
)

func main() {
	r := m.NewRouter()
	mw1 := mw("1")
	mw2 := mw("2")
	mw3 := mw("3")

	r.WithMiddlewares(mw1)
	r.Handle("/", dummyHandler("Index"))

	r.WithMiddlewares(mw1, mw2)
	r.Handle("/login", dummyHandler("Login"))
	r.Handle("/user", dummyHandler("User"))

	r.WithMiddlewares(mw1, mw2, mw3)
	r.Handle("/about", dummyHandler("About"))

	fmt.Printf("------------\n")
	http.ListenAndServe(":8080", r)

}

func mw(name string) func(h http.Handler) http.Handler {
	return func(h http.Handler) http.Handler {
		fmt.Printf("Evaluating Middleware %s\n", name)
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			fmt.Printf("[Middleware: %s]: %s\n", name, r.URL)
			h.ServeHTTP(w, r)
		})
	}
}

func dummyHandler(name string) http.Handler {
	fmt.Printf("Adding Handler for %s\n", name)
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, name)
	})
}

nadiamoe · 2017-10-02T15:04:11Z

I definitely don't like this. Using order of addition to define which middlewares affect which routes is completely intuitive.

nadiamoe · 2017-10-02T16:55:32Z

Status update: I moved middleware chain building from ServeHTTP() to Match().

This is because ServeHTTP() is called on the parent router, even if the match is a subrouter. See 9315e1c for details.

elithrar · 2017-10-02T17:09:02Z

Thanks Roberto. I'm pretty convinced that the router-scoped approach (as opposed to route-scoped) is the best one here, so will start reviewing this during the week. A good few examples in the README will go a long way too.

…

On Mon, Oct 2, 2017 at 5:55 PM Roberto Santalla ***@***.***> wrote: Status update: I moved middleware chain building from ServeHTTP() to Match(). This is because ServeHTTP() is called on the parent router, even if the match is a subrouter. See 9315e1c <9315e1c> for details. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcCOH1v1No1wr6XSSDSyQvp2Z8c5jks5soRWFgaJpZM4PRbdT> .

nadiamoe · 2017-10-02T19:13:58Z

No prob. I'll probably add a few test cases tomorrow, as well as code documentation and README manuals.

nadiamoe · 2017-10-03T14:36:16Z

Status update: Test cases added, brief documentation included in README.md and doc.go.

elithrar · 2017-10-13T10:48:11Z

Thanks Roberto! As a heads up, I am on vacation at the moment—without a “real” computer—but will try to get an initial first-pass review done between now and the end of next week!

…

On Tue, Oct 3, 2017 at 5:36 PM Roberto Santalla ***@***.***> wrote: Status update: Test cases added, brief documentation included in README.md and doc.go. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcMhmGtstUt4Vlxqo7k8J1PcvgqbGks5sokZhgaJpZM4PRbdT> .

nadiamoe · 2017-10-18T18:05:21Z

I've discovered an annoying bug on my implementation.

Middlewares aren't supposed to be run if no match is found, however, given how Router.Match() works right now, if a subrouter's Router.NotFoundHandler is not nil, the middleware will be executed, as the match is not nil.

This bug makes me think about the way mux handles this event: correct me if I'm wrong, but if a method mismatch occurs, Route.Match() returns false and sets matchError accordingly. However, if no route is found, instead of returning false and setting matchError to ErrMatchNotFound (or something like that), Router.Match() just returns true as if it were a normal match. Why does mux behaves this way?

Changing this behaviour as I described would allow an easy check for a not found event, and avoid building the middleware chain if it took place.

elithrar · 2017-10-29T19:32:41Z

Sorry for the slow reply @roobe - catching up on issues.

I'm not the original author for mux, so I can't explain precisely why it behaves that way.

I'm OK with:

Method mismatch (not-found) returning false and setting matchError
Route not-found returning false and setting matchError to ErrMatchNotFound

Notably, there may be valid cases where you still want middleware to execute when there is no match (logging all requests, for example!), so we should provide a way to account for that too.

nadiamoe · 2017-10-29T23:22:28Z

No prob, I agree with you in both points. I think it's best if I create a new PR for setting ErrMatchNotFound when falling back to NotFoundHandler, and then continuing on the middleware branch when it is merged. That should avoid unnecessary conflicts. Are you okay with that?

elithrar · 2017-10-29T23:36:31Z

Perfect - SGTM.

…

On Sun, Oct 29, 2017 at 4:22 PM Roberto Santalla ***@***.***> wrote: No prob, I agree with you in both points. I think it's best if I create a new PR for setting ErrMatchNotFound when falling back to NotFoundHandler, and then continuing on the middleware branch when it is merged. That should avoid unnecessary conflicts. Are you okay with that? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#293 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcI0mw4ty-ZvntAMzizZYmaSpdNhUks5sxQi1gaJpZM4PRbdT> .

nadiamoe · 2017-11-03T18:24:04Z

#311 created.

* mux.Router now has a `Use` method that allows you to add middleware to request processing.

elithrar · 2018-01-17T13:19:22Z

Closed in #294.

A new dev cycle means it's a good time to update. I had to remember to clear my glide cache before updating due to a long standing bug (see: Masterminds/glide#592). I was definitely motivated, to see if we can benefit from first-class middleware support in `gorilla/mux` (see: gorilla/mux#293).

nadiamoe mentioned this issue Sep 11, 2017

Add middleware support as discussed in #293 #294

Merged

elithrar added the enhancement label Sep 19, 2017

elithrar self-assigned this Sep 19, 2017

nadiamoe mentioned this issue Nov 3, 2017

MatchErr is set to ErrNotFound if NotFoundHandler is used #311

Merged

elithrar pushed a commit that referenced this issue Jan 16, 2018

[feat] Add middleware support as discussed in #293 (#294)

53c1911

* mux.Router now has a `Use` method that allows you to add middleware to request processing.

nadiamoe closed this as completed Jan 17, 2018

PR for middleware support #293

PR for middleware support #293

Comments

nadiamoe commented Sep 8, 2017

abdullah2993 commented Sep 11, 2017 • edited Loading

abdullah2993 commented Sep 11, 2017 • edited Loading

elithrar commented Sep 11, 2017 via email

nadiamoe commented Sep 11, 2017

elithrar commented Sep 11, 2017 via email

nadiamoe commented Sep 11, 2017 • edited Loading

abdullah2993 commented Sep 11, 2017

nadiamoe commented Sep 12, 2017

elithrar commented Sep 12, 2017 via email

nadiamoe commented Sep 12, 2017

elithrar commented Sep 12, 2017 via email

nadiamoe commented Sep 12, 2017

elithrar commented Sep 19, 2017

nadiamoe commented Sep 19, 2017

nadiamoe commented Sep 28, 2017

Key differences bewteen external and embedded middleware

Regarding the Middleware and MiddlewareFunc interfaces

elithrar commented Sep 28, 2017

nadiamoe commented Sep 28, 2017

elithrar commented Sep 28, 2017 via email

abdullah2993 commented Sep 28, 2017

nadiamoe commented Sep 28, 2017

abdullah2993 commented Sep 28, 2017 • edited Loading

nadiamoe commented Sep 29, 2017

nadiamoe commented Sep 29, 2017

abdullah2993 commented Sep 29, 2017 • edited Loading

elithrar commented Sep 29, 2017 via email

nadiamoe commented Sep 29, 2017

abdullah2993 commented Sep 30, 2017

nadiamoe commented Sep 30, 2017

abdullah2993 commented Sep 30, 2017 • edited Loading

elithrar commented Sep 30, 2017

abdullah2993 commented Sep 30, 2017

nadiamoe commented Oct 2, 2017

abdullah2993 commented Oct 2, 2017

nadiamoe commented Oct 2, 2017

nadiamoe commented Oct 2, 2017

elithrar commented Oct 2, 2017 via email

nadiamoe commented Oct 2, 2017

nadiamoe commented Oct 3, 2017

elithrar commented Oct 13, 2017 via email

nadiamoe commented Oct 18, 2017 • edited Loading

elithrar commented Oct 29, 2017

nadiamoe commented Oct 29, 2017 • edited Loading

elithrar commented Oct 29, 2017 via email

nadiamoe commented Nov 3, 2017

elithrar commented Jan 17, 2018

abdullah2993 commented Sep 11, 2017 •

edited

Loading

abdullah2993 commented Sep 11, 2017 •

edited

Loading

nadiamoe commented Sep 11, 2017 •

edited

Loading

Regarding the `Middleware` and `MiddlewareFunc` interfaces

abdullah2993 commented Sep 28, 2017 •

edited

Loading

abdullah2993 commented Sep 29, 2017 •

edited

Loading

abdullah2993 commented Sep 30, 2017 •

edited

Loading

nadiamoe commented Oct 18, 2017 •

edited

Loading

nadiamoe commented Oct 29, 2017 •

edited

Loading