Idiomatic golang net/http gzip transparent compression, an updated version of https://gist.github.com/bryfry/09a650eb8aac0fb76c24

gzip.go

package main

import (
        "net/http"
        "compress/gzip"
        "io/ioutil"
        "strings"
        "sync"
        "io"
)

var gzPool = sync.Pool {
        New: func() interface{} {
                w := gzip.NewWriter(ioutil.Discard)
                return w
        },
}

type gzipResponseWriter struct {
        io.Writer
        http.ResponseWriter
}

func (w *gzipResponseWriter) WriteHeader(status int) {
        w.Header().Del("Content-Length")
        w.ResponseWriter.WriteHeader(status)
}

func (w *gzipResponseWriter) Write(b []byte) (int, error) {
        return w.Writer.Write(b)
}

func Gzip(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
                if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {
                        next.ServeHTTP(w, r)
                        return
                }

                w.Header().Set("Content-Encoding", "gzip")

                gz := gzPool.Get().(*gzip.Writer)
                defer gzPool.Put(gz)

                gz.Reset(w)
                defer gz.Close()

                next.ServeHTTP(&gzipResponseWriter{ResponseWriter: w, Writer: gz}, r)
        })
}

I think the defer Close line should be before the defer gzpool.Put. To prevent any writes going to the writer before being put back on the pool.

I did a little benchmarking and I didn't see any improvement using sync pool. It was actually slower.

I did a little benchmarking and I didn't see any improvement using sync pool. It was actually slower.

Implementing a sync mechanism probably will make your code slower, but more memory efficient since you don't allocate a new gzip writer on every request.