PR for middleware support

[nadiamoe]

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.

[abdullah2993]

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]

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

[elithrar]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.