Prometheus JMX exporter incorrectly returns both Content-Length and Transfer-Encoding response headers for gzip compressed response in JBoss EAP image.

However, RFC 7230 - Section 3.3.2. Content-Length (and also the latest RFC 9112 - Section 6.2. Content-Length) expressly forbid returning both Content-Length and Transfer-Encoding response headers in a response.

A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.

—

The same issue has been reported in the upstream: https://github.com/prometheus/jmx_exporter/issues/304

Fixed by https://github.com/prometheus/client_java/pull/413

—

As reported in the above upstream issue, this can be easily reproducible by using curl to send a request with the "Accept-Encoding" request header having "gzip" ("Accept-Encoding: gzip" or "Accept-Encoding: gzip, deflate", etc) in the EAP 7 image which enables prometheus-jmx-exporter with setting the environment variable AB_PROMETHEUS_ENABLE to true. For example:

sh-4.2$ curl -v http://localhost:9799/metrics -H "Accept-Encoding: gzip" > /dev/null
...(snip)...
> GET /metrics HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:9799
> Accept: */*
> Accept-Encoding: gzip
> 
< HTTP/1.1 200 OK
< Content-encoding: gzip
< Date: Fri, 16 Jun 2023 10:15:56 GMT
< Transfer-encoding: chunked
< Content-type: text/plain; version=0.0.4; charset=utf-8
< Content-length: 16083
< 
...(snip)...