Skip to content

Use http.DefaultTransport.Clone() in UAA version check to preserve default settings for Integration Tests #3653

@anujc25

Description

@anujc25

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=1 to 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:

  1. Run integration tests that check UAA version compatibility
  2. It will not be able to get the UAA version as the code is not respecting the https_proxy configuration when creating http client.
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions