>> AFAIK, there is (still?) no out-of-the-box support for gzip. I believe this is the answer. I figured I'd fish around to see if anyone had already solved and open sourced a solution to this problem.
>> See, for example, https://github.com/NYTimes/gziphandler While certainly related, this example only provides gzip _compression_ for responses emitted from an HTTP server when the request has the appropriate accept-encoding header. I'm also looking to gzip _decompress_ the incoming request bodies when they are marked with an appropriate content-encoding header. On Sat, Mar 4, 2017 at 4:16 PM John Kemp <[email protected]> wrote: > AFAIK, there is (still?) no out-of-the-box support for gzip. > > See, for example, https://github.com/NYTimes/gziphandler > > - johnk > > > On Mar 4, 2017, at 5:11 PM, Kevin Conway <[email protected]> > wrote: > > > > I'm running a go 1.7 HTTP server. One of my clients is applying gzip to > the POST body of their request and applying the appropriate > content-encoding header. The current server implementation in go, unlike > the client, does not appear to automatically handle decompression of the > body. This is causing calls to JSON unmarshal to fail because it, rightly, > expects uncompressed data to work with. > > > > Certainly, we could add our own gzip reader on top of the request body > to handle this. It seems strange, though, that this case is accounted for > in the go HTTP client but not the server. > > > > Have I missed something obvious? > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
