Code change:
} } <ins> func TestDiscoveryContentTypeVersion(t *testing.T) { tests := []struct { contentType string isV2Beta1   bool }{ { contentType: "application/json; g=apidiscovery.k8s.io;v=v2beta1;as=APIGroupDiscoveryList", isV2Beta1:   true, }, { // content-type parameters are not in correct order, but comparison ignores order. contentType: "application/json; v=v2beta1;as=APIGroupDiscoveryList;g=apidiscovery.k8s.io", isV2Beta1:   true, }, { // content-type parameters are not in correct order, but comparison ignores order. contentType: "application/json; as=APIGroupDiscoveryList;g=apidiscovery.k8s.io;v=v2beta1", isV2Beta1:   true, }, { // Ignores extra parameter "charset=utf-8" contentType: "application/json; g=apidiscovery.k8s.io;v=v2beta1;as=APIGroupDiscoveryList;charset=utf-8", isV2Beta1:   true, }, { contentType: "application/json", isV2Beta1:   false, }, { contentType: "application/json; charset=UTF-8", isV2Beta1:   false, }, { contentType: "text/json", isV2Beta1:   false, }, { contentType: "text/html", isV2Beta1:   false, }, { contentType: "", isV2Beta1:   false, }, } for _, test := range tests { isV2Beta1 := isV2Beta1ContentType(test.contentType) assert.Equal(t, test.isV2Beta1, isV2Beta1) } } </ins> func TestUseLegacyDiscovery(t *testing.T) { // Default client sends aggregated discovery accept format (first) as well as legacy format. server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) {

Related discussion:
text: We are using (and ) to interact with Kubernetes clusters behind a couple of proxy layers. One of these proxies completes the headers to include character encoding details. This was working fine until recently, when client-go/kubectl have started to fail when interacting with the discovery API. It seems that a recent change has made kubectl more restrictive of the content-type that it expects. I suspect that it is related to this commit: For example, this is an error from a kubectl command: We can of course try to fix it on our end, removing that charset information. However, it is a valid content-type and the way kubectl is handling the content-type there seems like it is relying on implementation details of kube-apiserver (that it does not add metadata to the content-type). I propose to fix this issue in , by properly parsing and handling the content-type.
cc /kind regression /kind bug /sig api-machinery /priority important-soon looks like the switch statement in downloadLegacy() needs to be more tolerant of the variety of content-types it can get from a server (including text/plain or no content-type if old servers could have returned that...)
/transfer kubernetes/kubernetes
Something went wrong or the destination repo kubernetes/kubernetes/kubernetes does not exist. <detailsIn response to : /transfer kubernetes/kubernetes Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/transfer kubernetes
Yep, the string comparison for the content-type is flimsy, let's address that. Thanks for the report!
/assign
/triage accepted
/cc
The fix is being cherry-picked back to: : :