[kgeckhart]

Optionally allow gzip and zstd compression while Senders and Receivers still MUST support snappy.

RW2 with snappy sends roughly 1.8x the bytes of OTLP with gzip. gzip or zstd closes that gap and still costs less CPU than OTLP (encode, decode benchmarks).

The 2.0 proposal held off on new compressions over receiver-side CPU cost. Keeping gzip and zstd a SHOULD for Receivers leaves that choice with them. I'm not sure if we should update the proposal if we merge this?

Related to: prometheus/prometheus#13366

[bwplotka]

Nice! Some suggestions, otherwise looks great.

Thanks!

[bwplotka]

Since gzip and zstd are SHOULD for Receivers and 415 retry is MAY for Senders, Senders SHOULD still default to snappy unless configured otherwise or advertised via Accept-Encoding so 2.x Senders and snappy-only Receivers interoperate out of the box. Also, MUST only be used leaves it ambiguous whether HTTP decompression middlewares running before Content-Type parsing must reject prometheus.WriteRequest compressed with gzip or zstd:

Suggested change

	Senders and Receivers MUST support `snappy`. Receivers SHOULD support `gzip` and `zstd`. `gzip` and `zstd` MUST only be used with `io.prometheus.write.v2.Request`.
	Senders and Receivers MUST support `snappy`. Receivers SHOULD support `gzip` and `zstd`. Senders MAY support `gzip` and `zstd`, and SHOULD use `snappy` by default unless configured otherwise or advertised by the Receiver via `Accept-Encoding`. Senders MUST NOT use `gzip` or `zstd` with `prometheus.WriteRequest`, and Receivers MAY reject such requests with `415 HTTP Unsupported Media Type`.

[bwplotka]

If a Receiver pool sits behind an L7 load balancer during a rolling update or rollback, upgrading from a 2xx Accept-Encoding header without 415 retry support will drop batches when subsequent requests hit snappy-only replicas, or flip-flop across replicas. Also, RFC 9110 obsoleted RFC 7694 and folded response Accept-Encoding directly into Section 12.5.3:

Suggested change

Receivers MAY include the `Accept-Encoding` response header on 2xx responses to advertise supported `Content-Encoding` values, as defined in [RFC 7694](https://www.rfc-editor.org/rfc/rfc7694.html). Senders MAY use it to choose a supported encoding for subsequent requests.

Receivers MAY include the `Accept-Encoding` response header on 2xx responses to advertise supported `Content-Encoding` values for that request, as defined in [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-encoding). Senders using `io.prometheus.write.v2.Request` MAY use it to choose an allowed encoding for subsequent requests, in which case they MUST fall back to `snappy` and retry on `415 HTTP Unsupported Media Type` and SHOULD avoid immediately re-upgrading across load-balanced Receiver replicas.

[bwplotka]

Keeping Accept as an unconditional SHOULD on all 415 responses means decompression middlewares like SnappyDecodeMiddleware or reverse proxies violate SHOULD when rejecting Content-Encoding before the inner handler knows accepted ;proto= and ;mode= values. Maybe scope Accept to Content-Type rejections per RFC 9110 Section 15.5.16 and link RFC 9110 Section 12.5.3 instead of obsoleted RFC 7694:

Suggested change

Receivers MUST return [415 HTTP Unsupported Media Type](https://www.rfc-editor.org/rfc/rfc9110.html#name-415-unsupported-media-type) status code if they don't support a given content type or encoding provided by Senders. When returning `415 HTTP Unsupported Media Type`, Receivers SHOULD include the `Accept` response header (listing supported `Content-Type` values, including supported `;proto=` and `;mode=` parameters) so Senders can determine what the Receiver supports without guessing. If the 415 is due to an unsupported `Content-Encoding`, Receivers SHOULD also include the `Accept-Encoding` response header listing supported `Content-Encoding` values. Otherwise, in a 415 response, Receivers MUST NOT include `Accept-Encoding`, as defined in [RFC 7694](https://www.rfc-editor.org/rfc/rfc7694.html).

Receivers MUST return [415 HTTP Unsupported Media Type](https://www.rfc-editor.org/rfc/rfc9110.html#name-415-unsupported-media-type) status code if they don't support a given content type or encoding provided by Senders. If the 415 is due to an unsupported `Content-Type`, Receivers SHOULD include the [`Accept`](https://www.rfc-editor.org/rfc/rfc9110.html#name-accept) response header listing supported `Content-Type` values, including supported `;proto=` and `;mode=` parameters, so Senders can determine what the Receiver supports without guessing. If the 415 is due to an unsupported `Content-Encoding`, Receivers SHOULD include the [`Accept-Encoding`](https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-encoding) response header listing supported `Content-Encoding` values. Receivers that return 415 for reasons unrelated to `Content-Encoding` MUST NOT include `Accept-Encoding`, as defined in [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-encoding).

[bwplotka]

Suggested change

	Content encoding request header MUST follow [the RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-content-encoding). The allowed values are:
	Content encoding request header MUST follow [the RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-content-encoding). Senders are allowed to use following values:

I'd use the specific form as much as possible to be precise

[bwplotka]

The 2.0 proposal held off on new compressions over receiver-side CPU cost. Keeping gzip and zstd a SHOULD for Receivers leaves that choice with them. I'm not sure if we should update the proposal if we merge this?

Proposal is completely out of sync at this point. However it tried to explain history of certain changes and its motivation. Perhaps we close the proposal and write a biggy blog post for this. Not sure yet. Fine to skip for now.