open-nomad/.changelog/11843.txt

```release-note:improvement
deps: use gorilla package for gzip http handler
```
deps: adjust to gzip handler zero length response body After swapping gzip handler to use the gorilla library, we must account for a quirk in how zero/minimal length response bodies are delivered. The previous gzip handler was configured to compress all responses regardless of size - even if the data was zero length or below the network MTU. This behavior changed in [v1.1.0](https://github.com/nytimes/gziphandler/commit/c551b6c3b4b976eafa1a18220b5e21692784d8e2#diff-de723e6602cc2f16f7a9d85fd89d69954edc12a49134dab8901b10ee06d1879d) which is why we could not upgrade. The Nomad HTTP Client mutates the http.Response.Body object, making a strong assumption that if the Content-Encoding header is set to "gzip", the response will be readable via gzip decoder. This is no longer true for the nytimes gzip handler, and is also not true for the gorilla gzip handler. It seems in practice this only makes a difference on the /v1/operator/license endpoint which returns an empty response in OSS Nomad. The fix here is to simply not wrap the response body reader if we encounter an io.EOF while creating the gzip reader - indicating there is no data to decode. 2022-01-13 15:57:36 +00:00			```release-note:improvement
			`deps: use gorilla package for gzip http handler`
			```