Fix content type fallback when a client defaults to CBOR.

With the ClientsAllowCBOR client-go feature gate enabled, a 415 response to a CBOR-encoded REST
causes all subsequent requests from the client to fall back to a JSON request encoding. This
mechanism had only worked as intended when CBOR was explicitly configured in the
ClientContentConfig. When both ClientsAllowCBOR and ClientsPreferCBOR are enabled, an
unconfigured (empty) content type defaults to CBOR instead of JSON. Both ways of configuring a
client to use the CBOR request encoding are now subject to the same fallback mechanism.

Kubernetes-commit: a77f4c7ba2e761461daaf115a38903fc91916dd6
This commit is contained in:
Ben Luddy
2024-11-07 00:05:03 -05:00
committed by Kubernetes Publisher
parent c57dbd8dec
commit 49537610e8
2 changed files with 27 additions and 20 deletions

View File

@@ -156,14 +156,10 @@ func NewRequest(c *RESTClient) *Request {
timeout = c.Client.Timeout
}
contentConfig := c.content.GetClientContentConfig()
contentTypeNotSet := len(contentConfig.ContentType) == 0
if contentTypeNotSet {
contentConfig.ContentType = "application/json"
if clientfeatures.FeatureGates().Enabled(clientfeatures.ClientsAllowCBOR) && clientfeatures.FeatureGates().Enabled(clientfeatures.ClientsPreferCBOR) {
contentConfig.ContentType = "application/cbor"
}
}
// A request needs to know whether the content type was explicitly configured or selected by
// default in order to support the per-request Protobuf override used by clients generated
// with --prefers-protobuf.
contentConfig, contentTypeDefaulted := c.content.GetClientContentConfig()
r := &Request{
c: c,
@@ -176,7 +172,7 @@ func NewRequest(c *RESTClient) *Request {
warningHandler: c.warningHandler,
contentConfig: contentConfig,
contentTypeNotSet: contentTypeNotSet,
contentTypeNotSet: contentTypeDefaulted,
}
r.setAcceptHeader()