How to use custom http handlers/middleware if headers already set?

Question

I'm trying to chain HTTP handlers in go to provide some added functionality, like this:

package router

import (
    // snip
    "github.com/gorilla/mux"
    "github.com/gorilla/handlers"
    "net/http"
)

// snip

r := mux.NewRouter()
/* routing code */
var h http.Handler
h = r
if useGzip {
    h = handlers.CompressHandler(h)
}
if useLogFile {
    fn := pathToLog
    accessLog, err := os.OpenFile(fn, os.O_WRONLY|os.O_APPEND|os.O_CREATE, 0666)
    if err != nil {
        panic(err)
    }
    h = handlers.CombinedLoggingHandler(accessLog, h)
}

// etc...

The problem is, if any HTTP headers are already set by one of the controllers that the gorilla/mux router points to (for example, w.WriteHeader(404) or w.Header().Set("Content-Type", "application/json")) - this silently breaks any "wrapper" handler trying to set or add its own headers, like the compress handler. I can't see any errors, unless I forgot to catch one somewhere, but the browser gets an invalid response.

Is there any graceful way to deal with this, short of just stashing the headers somewhere and then leaving the final handler to write them? It seems like that would mean rewriting the handlers' code, which I'd love to avoid if at all possible.

Answer 1

Once you call w.WriteHeader(404), the header goes on a wire. So you can't add to it anymore. Best way you can do is to buffer status code and write it at the end of a chain.

For example, you can provide your own wrapper for http.ResponseWriter that would re-implement WriteHeader() to save status value. Then add method Commit() to actually write it. Call Commit() in the last handler. You have to determine somehow which handler is last, of course.

Answer 2

I experienced the same silently-failing behaviour. But only in handlers where I did WritheHeader to set a status code other than StatusOK. I think things went wrong in this part of CompressHandler:

if h.Get("Content-Type") == "" {
    h.Set("Content-Type", http.DetectContentType(b))
}

Which appears to be resolved when explicitly setting the content type in my own handler:

w.Header().Set("Content-Type", "text/html; charset=utf-8")
w.WriteHeader(code)