-
Notifications
You must be signed in to change notification settings - Fork 989
Description
Please fill out the issue checklist below and provide ALL the requested information.
- I reviewed open and closed github issues that may be related to my problem.
- I tried updating to the latest version of the CF CLI to see if it fixed my problem.
- I attempted to run the command with
CF_TRACE=1to help debug the issue. - I am reporting a bug that others will be able to reproduce.
Describe the bug and the command you saw an issue with
When running integration tests that check UAA version compatibility (IsUAAVersionAtLeast function in integration/helpers/version.go), the HTTP client was manually creating a new http.Transport with minimal configuration, only setting TLSClientConfig. This approach bypassed Go's http.DefaultTransport settings, which include important defaults like:
- HTTP/2 support
- Connection pooling settings
- Proper timeout configurations
- MaxIdleConns and IdleConnTimeout settings
- Other performance and reliability optimizations
- Respecting Proxy configurationUse http.DefaultTransport.Clone() in UAA version check to preserve default settings
This could lead to suboptimal HTTP client behavior during integration tests, potentially causing flaky tests or unexpected connection handling issues.
What happened
The UAA version check in integration tests used a manually constructed http.Transport:
tr := &http.Transport{
TLSClientConfig: &tls.Config{InsecureSkipVerify: SkipSSLValidation()},
}
This minimal transport configuration missed all the beneficial defaults provided by Go's standard library.
Expected behavior
The HTTP transport should preserve all default transport settings from http.DefaultTransport while still allowing custom TLS configuration to be applied. This ensures:
- Better HTTP/2 support when available
- Proper connection pooling and reuse
- Standard timeout and keep-alive configurations
- Consistent behavior with other HTTP clients in the codebase
Exact Steps To Reproduce
This issue affects integration test execution rather than user-facing CLI commands. The problem would manifest when running tests with https_proxy set:
- Run integration tests that check UAA version compatibility
- It will not be able to get the UAA version as the code is not respecting the
https_proxyconfiguration when creating http client. - Causes the test run to fail.
Provide more context
- This fix applies to the integration test helpers in
integration/helpers/version.go - The issue is a code quality improvement that follows Go best practices
- Similar patterns exist throughout the codebase in other connection initialization code (e.g.,
api/cloudcontroller/cloud_controller_connection.go,api/uaa/uaa_connection.go,api/plugin/plugin_connection.go) - Future consideration: Audit other HTTP transport creation instances in the codebase to ensure they follow this pattern where appropriate
Notes regarding V6 and V7 CLI support:
N/A
Additional Context
This is a technical debt fix that improves code quality and test reliability. While it doesn't fix a user-reported bug, it ensures the integration tests use proper HTTP client configuration that aligns with Go standard library