Closed achille-roussel closed 6 months ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Hello,
I am opening this issue to discuss a potential misuse of
http.DefaultClient
inrest.HTTPClientFor
. The function appears to make the assumption thathttp.DefaultClient
will always usehttp.DefaultTransport
, which may not be the case.For context, this is the function in question: https://github.com/kubernetes/client-go/blob/0cde78477a6d3ec3682b922654942a9a21f3a9eb/rest/transport.go#L38-L45
Take this code as example:
In this example, invocations of
rest.HTTPClientFor
which resolve the transport tohttp.DefaultTransport
will mistakenly assume that they can use the default client because the configuration ofhttp.DefaultClient.Transport
may not matchhttp.DefaultTransport
anymore.The check to fallback to
http.DefaultClient
inrest.HTTPClientFor
seems to be intended as an optimization. Fixing the implementation could look like this:However, this fix example highlights the tight coupling between this optimization and the inner implementation of
http.Client
. I would like to suggest removing it and always creating a newhttp.Client
regardless of which transport is resolved from the configuration to simplify the code and avoid regressions that could be difficult to anticipate or track down.To summarize, the function would be modified to always do:
Happy to submit the fix if there is a consensus on the issue.