Content negotiation is broken for expfmt and for promhttp

[jonatan-ivanov]

According to this comment on OTel's Prometheus exporter expfmt and promhttp are returning the wrong format if openmetrics-text 1.0.0 is requested. It seems openmetrics-text 1.0.0 is not supported only openmetrics-text 0.0.1 is.

If a user requests openmetrics-text 1.0.0:

Accept: application/openmetrics-text; version=1.0.0; charset=utf-8

The expected result should be in the OpenMetrics format, also the content-type should be:

Content-Type: application/openmetrics-text; version=1.0.0; charset=utf-8

But the result is in Prometheus plaintext format, the content-type says the same:

Content-Type: text/plain; version=0.0.4; charset=utf-8

If a user requests openmetrics-text 0.0.1:

Accept: application/openmetrics-text; version=0.0.1; charset=utf-8

The result is in the expected OpenMetrics format:

Content-Type: application/openmetrics-text; version=0.0.1; charset=utf-8

As far as I know, 0.0.1 should not be used, only 1.0.0.
According to the OpenMetrics specs:

The content type MUST be: application/openmetrics-text; version=1.0.0; charset=utf-8

Also the Prometheus server uses 1.0.0 for scraping: prometheus/prometheus#9430

[jonatan-ivanov]

@roidelapluie Could you please help out here a little?
I think one of the the consequences of this issue is that Prometheus is not fully compatible with itself/not consistent.

[gouthamve]

Hi this is a valid bug. And the only reason nobody noticed it because Prometheus also sends version=0.0.1 in its accept header.

https://github.com/prometheus/prometheus/blob/main/scrape/scrape.go#L775

I'll send a PR fixing it now.

[jonatan-ivanov]

noticed it because Prometheus also sends version=0.0.1

I'm aware (I made that change). Since the OpenMetrics output is not necessarily scraped by Prometheus and the OpenMetrics spec says this:

The content type MUST be: application/openmetrics-text; version=1.0.0; charset=utf-8

I guess this is mostly about following the specs and other consumers being broken.