Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

ref issue #44164

This got implemented in #45666, reverted, and implemeted again (gated off by default) in #46966 (commit b74e5942e2a7ef9f73874b7e5a48c030ff7f1189 in this repo).

There is #51508 still open to enable it by default.

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

/remove-lifecycle rotten

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

☹

/transfer kubernetes

BTW, for extra credit: support hop-by-hop compression too.

Of course, kubectl doesn't yet support hop-by-hop compression, but some generic tools (eg curl) do.

Clients can combine what they negotiate, too: for example, preferring application/vnd.kubernetes.protobuf data and also advertising that they support either identity or br hop-by-hop transfer encoding.

You don't have to restrict compression to JSON response bodies (per the issue title)

…or even to responses. The API server can allow clients to hop-by-hop compress a request body, too (using the Expect: 100-continue mechanism).

Because clients that understand hop-by-hop compression typically implement it properly, and only for HTTP/1.1 requests, adding hop-by-hop compression support is low impact / low risk. We could implement that first to get feedback on the implementation and then later migrate to end-to-end compression (which clients and proxies often do get wrong).

PS. https://datatracker.ietf.org/doc/html/rfc7540 forbids HTTP/2 clients from requesting hop-by-hop response body compression, and it looks like HTTP/3 will forbid it too. I'm not suggesting that hop-by-hop compression for those protocols is likely; that's a different and bigger question.

/sig api-machinery

/priority backlog

/triage accepted
/help

@fedebongio:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

Interestingly the original issue should be fixed, accept encoding is what we key compression off of. Possible to close?

As per #77449 this has been in Kube for a while. Please reopen if the original request was different. Re: hop by hop that should be a separate issue.