not setting Content-Type at the right time is confusing; was: negotiation fails with safari
Closed this issue · 6 comments
Safari sends gzip, deflate, br as its Accept-Encoding value. There are no weights.
I am not certain, but it seems the parsing expects something more complex?
Maybe here? https://github.com/andybalholm/brotli/blob/master/http.go#L74
Do I misunderstand?
If this is an issue, would you accept a patch to fix it?
The parsing is supposed to handle more complicated headers, or simple ones like that.
You say the negotiation fails; what actually happens?
Oh durp. That all works fine. My issue was not setting Content-Type at the right time, which you have well documented. Sorry about the noise. Thank you for the response.
Maybe docs which show how to use it with setting Content-Type would help? I'd contribute them, if I knew how to do it :)
Just set the Content-Type (with w.Header().Set) before calling HTTPCompressor.
That makes it impossible to drop into a middleware, doesn't it?
...
r := http.NewServeMux()
r.HandleFunc("/admin", authnCheck(admin))
r.Handle("/", http.FileServer(http.FS(fs)))
...
log.Fatal(http.ListenAndServe(":8000",
compress(r)))
...
func compress(fn http.Handler) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
// how to call HTTPCompressor here?
}
}
If worked around it myself by not using HTTPCompressor, so if this isn't something you are interested in this package doing, that is fine.
Since golang/go#31753 has been fixed for a good while now, we can probably remove the check for the Content-Type header, and allow compressing without the CT set.