Add WrapHandler to the main docs about docs

[dankinder]

Actually misspoke here. Though WrapHandler is useful I was thinking of middleware, not handlers. Would be great if there were a good example of wrapping standard middleware to make it work with buffalo.

[markbates]

Can you elaborate on what you mean by "standard middleware"? There is no concept of middleware in the standard library, only third party implementations.

[dankinder]

Yeah for sure. You're right that there is no standard middleware interface definition, but this pattern is quite common:

func myMiddleware(next http.Handler) http.Handler {
  return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    // do some stuff ...
    next.ServeHTTP(w, r)
  })
}

An example library that provides middleware with this pattern, that we used: https://github.com/NYTimes/gziphandler

I guess this is a question: is there an easy way to nab a middleware library like this and use it in buffalo?

[markbates]

It is possible, it would look something like this:

app.Use(func(next buffalo.Handler) buffalo.Handler {
	return func(c buffalo.Context) error {
		return buffalo.WrapHandler(myMiddleware(http.HandlerFunc(func(res http.ResponseWriter, req *http.Request) {
			next(c)
		})))(c)
	}
})

Not pretty, however, that could easily be made into a function that did all that. You feel like getting your hands dirty with a PR? :)

[dankinder]

Hm, that won't work will it?

For example middleware like NYTimes/gziphandler (https://github.com/NYTimes/gziphandler/blob/master/gzip.go#L240) works by returning a new ResponseWriter wrapping the provided one with its own. I think what you posted will cause the new wrapped ResponseWrite not to be used since the buffalo context will still the ResponseWriter that was passed in with it.

It may be possible to work around this flaw, if I'm right. May send a PR when I have time for one, especially if I'm putting it to use!

[markbates]

This can now be done in v0.9.4, https://blog.gobuffalo.io/buffalo-v0-9-4-released-5d2327a4742e, so I'm closing this issue. Feel free and re-open if you have problems.

[dankinder]

Right on, thanks!

[dreampuf]

I'm not sure that have you test it out. But I found that even PreWare can't play with the responsewriter replacing. It's just another middleware between http.Handler and buffalo.Context.

There is no way to replace the responsewriter, so you only can do the gzip writer in buffalo.Handler.

[UberMeatShield]

Posting here in case it might some day help somebody, one potentially abusive but seemingly working option is that you can just use the Response and Writer from the c buffalo.Context directly.

// Initialized like this
app.GET("/view/{dir_id}/{file_id}", ViewHandler)

// Used in a semi abusive fashion but lets you serve a file using the standard Response, Request format many libraries demo
 func ViewHandler(c buffalo.Context) error {
     dir_to_list := c.Param("dir_id")
     file_id := c.Param("file_id")
     fq_name = SomeAbsPathLookup(dir_id, file_id)
     if fq_name != nil {
         http.ServeFile(c.Response(), c.Request(), fq_name) // from net/http
         return nil   // I guess this compiles and doesn't complain in the logs!
     } else {
         return c.Render(404, r.JSON(invalidDirMsg(dir_to_list, file_id)))
     }
 }