Split Compressors into request / accept compressions.

[j16sdiz]

Transparent compression on request and decompression on response should be two independent options.

Currently, the Accept-Encoding: gzip and Content-Encoding: gzip are both controlled by the Compression option.

A survey of desktop browsers found none of them are sending gzipped content in request, but all of them are accepting gzipped content in response. PHP, Apache and Nginx have build-in constructs to do gzip on response. Only Apache can do decompression on request.
To have maximum compatibility, two options should be controlled separately.

[marcosnils]

@sschepens thoughts?

[sschepens]

Hmm, goreq is just an client, it's not a server like Apache or Nginx, all HTTP clients I know of tend to offer just a single option that turns on compression.
It just seems odd that someone would want to get response compressed but not send the request body compressed, if the server supports compressing response it should support decompressing the request body.
Browsers tend to do mostly GETs which don't have body, so these requests will never be compressed. I don't know how they treat POST requests.

Of course It's doable and shouldn't be difficult, I just don't see any real gain, but of course if this is preventing someone from using goreq then we should do it.

[j16sdiz]

No, neither wget nor curl do compression on request. They only add accept-encoding: gzip and do transparent decompression.
In fact, I have yet to see any general purpose http client do request compression.

[marcosnils]

We spoke about this with @sschepens and came to the conclussion of disabling request compression by default when Compression is supplied but allow a way to enable it through some other parameter (in case it's necessary). This is pretty much what @j16sdiz was suggesting in a first place.

@j16sdiz @sschepens does that work for you?

[sschepens]

@j16sdiz request compression is necessary when batch-sending data to a service such as elasticsearch for example.

@marcosnils yes, this is ok for me, as long as it's possible to turn on request compression it's ok.

[j16sdiz]

The default go http transport add "Accept-Encoding: gzip" and do transparent decompression if you don't specify any Accept-Encoding.

See
https://github.com/golang/go/blob/master/src/net/http/transport.go#L95
https://github.com/golang/go/blob/master/src/net/http/transport.go#L1126