feature request: support zstd negotiation within gzhttp

[mattrobenolt]

It'd be nice to transparently support both gzip and zstd based on just negotiating the Accept-Encoding header.

I'm happy to take a stab at implementing, but my only minor concern is that gzhttp is very specifically nammed "Gzip HTTP" rather than a more generic "compress http" or something.

But zstd is already supported within gzhttp as a transport encoding, but not for a normal HTTP response.

[klauspost]

Wrt naming, it is what it is. I don't expect a v2 any time soon, so we must remain compatible.

• GzipResponseWriter* - you are welcome to do a ZstdResponseWriter, if that makes sense. But if it makes more sense to do just one, just keep the name.

You are free to do what makes sense in that regard as long as there is a reason for what you are doing and you stay compatible.

If we use moderate default settings (default compression, small window - something like 64K) I don't mind turning it on by default.

(Moving to Discussion)

[figuerom16]

I'd be happy with a zshttp for zstd and ignoring Safari browsers... I think that would mean duplicating a bit of code.

Since we have a convenient way of deciding our own compression middleware it could look like:

func Compress(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		switch enc := r.Header.Get("Accept-Encoding"); {
		case strings.Contains(enc, "zstd"):
			zshttp.ZstdHandler(next).ServeHTTP(w, r)
		case strings.Contains(enc, "gzip"):
			gzhttp.GzipHandler(next).ServeHTTP(w, r)
		default:
			next.ServeHTTP(w, r)
		}
	})
}