feat: add gzip support for /metrics

[fatelei]

What is pr do ?

Let pushgateway server handle gzip content-encoding content.

Tests

Accept gzip

• server

• client

Forbid gzip

• server

• client

[beorn7]

Thanks for doing this. This seems to work in general, but most importantly, we have to add it in a way that the default behavior is the same as the current one (no compression, even if requested). See comments (which also include some nit-picking).

[beorn7]

Initially, you used github.com/NYTimes/gziphandler , but now you dropped it. Any reason for that? It seems reasonable to me to reuse that battle-tested middleware instead of implementing our own here.

In different news, you need to switch off gzip compression in the promhttp.HandlerOpts (line 137). Otherwise you might get double gzip compression.

[fatelei]

Initially, you used github.com/NYTimes/gziphandler , but now you dropped it. Any reason for that? It seems reasonable to me to reuse that battle-tested middleware instead of implementing our own here.

In different news, you need to switch off gzip compression in the promhttp.HandlerOpts (line 137). Otherwise you might get double gzip compression.

#84 need a feature, send Content-Encoding: gzip content to push gateway, so pushgateway need handle gzip format content in request. While github.com/NYTimes/gziphandler just make a gzip format response, it can not handle gzip format request.

[beorn7]

My apologies for only realizing now that #84 only talks about gzip'ing the body of a request, which is not handled at all by the usual gzip handlers (which are only concerned about response compression).

I think I understand now. Good news is that it makes things easier in terms of behavior change. We don't even need a flag because the request encoding isn't really connected to content negotiations. So far, a gzip'd request was just failing, so we can simply always allow it now. The response encoding will be untouched by all of that.

For remaining things to do, see comments below that, hopefully, make more sense now. My apologies again.

Also, could you add a short section to the README.md about the new feature? Perhaps at the end of the API section? Along the lines: "The body of a POST or PUT request may be gzip-compressed. Add a header Content-Encoding: gzip to do so." And then perhaps a curl example like echo "some_metric 3.14" | gzip | curl -H 'Content-Encoding: gzip' --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job

[fatelei]

My apologies for only realizing now that #84 only talks about gzip'ing the body of a request, which is not handled at all by the usual gzip handlers (which are only concerned about response compression).

I think I understand now. Good news is that it makes things easier in terms of behavior change. We don't even need a flag because the request encoding isn't really connected to content negotiations. So far, a gzip'd request was just failing, so we can simply always allow it now. The response encoding will be untouched by all of that.

For remaining things to do, see comments below that, hopefully, make more sense now. My apologies again.

Also, could you add a short section to the README.md about the new feature? Perhaps at the end of the API section? Along the lines: "The body of a POST or PUT request may be gzip-compressed. Add a header Content-Encoding: gzip to do so." And then perhaps a curl example like echo "some_metric 3.14" | gzip | curl -H 'Content-Encoding: gzip' --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job

OK

[beorn7]

Thank you very much for your contribution and your patience. I only have a few formatting nits left for the README.md file.

[beorn7]

Thank you very much again. Merging now.