Content-Encoding: gzip sent in 204 responses, breaks some clients

[mark-rushakoff]

curl -vvv -XPOST -H 'Accept-Encoding: gzip' 'localhost:8086/write?db=junk&precision=us' --data-binary 'x n=1i'
*   Trying ::1...
* Connected to localhost (::1) port 8086 (#0)
> POST /write?db=junk&precision=us HTTP/1.1
> Host: localhost:8086
> User-Agent: curl/7.43.0
> Accept: */*
> Accept-Encoding: gzip
> Content-Length: 6
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 6 out of 6 bytes
< HTTP/1.1 204 No Content
< Content-Encoding: gzip
< Request-Id: 988f51ba-1939-11e6-806b-000000000000
< X-Influxdb-Version: unknown
< Date: Fri, 13 May 2016 18:36:24 GMT
<
* Connection #0 to host localhost left intact

I'm using a client library that crashes when it sees Content-Encoding: gzip and tries to read the 0-length body (and I am going to file a separate issue on that client library). I can work around this by sending my writes with Accept-Encoding: identity.

I tried to see whether Content-Encoding: gzip on a 204 response was standards-compliant, but I wasn't able to find a clear answer on Google. I didn't want to spend the time to comb through any RFCs for an answer.

There is precedent in labstack/echo#489 for not sending Content-Encoding: gzip on 204 responses, and I think InfluxDB should follow suit. That issue also points out that "nginx warns about empty responses (HTTP 204) with a Content-Encoding header set".

(FWIW someone else ran into this same issue last September against 0.9.3 but seemingly didn't open an upstream bug with us.)