You'll need to handle it yourself. Gzipped requests (unlike responses) are
somewhat nonstandard.
(With a response, the client can say it supports gzip, but with requests,
you basically have to prenegotiate it out-of-band -- at least, that's how
I've encountered it in the past.)
On Mar 4, 2017 4:5
>> 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
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 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 appl
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
