Skip to content

Reduce latency from unsuccessful HTTPS upgrade after plaintext HTTP 400 #2580

Description

@coderabbitai

Summary

The HTTPS upgrade logic added in PR #2577 retries an automatic plaintext HTTP probe that receives an HTTP 400 response. If the target is cleartext-only or otherwise does not support HTTPS, the HTTPS retry can consume the full probe timeout before httpx restores the original plaintext HTTP result.

Required changes

Evaluate and implement a bounded strategy that reduces or avoids the latency from an HTTPS retry that cannot succeed. Preserve the scheme-detection behavior for TLS-only services that initially return HTTP 400 to a plaintext probe.

Rationale

The existing retry is correct for TLS-only services, but an unsuccessful retry adds avoidable latency for affected targets.

Affected areas

  • runner/runner.go: HTTPS upgrade and fallback logic in analyze.
  • runner/runner_test.go: Regression coverage for cleartext HTTP 400 responses and unsuccessful HTTPS upgrade attempts.

Acceptance criteria

  • A plaintext HTTP 400 result remains available when the HTTPS upgrade attempt fails.
  • TLS-only services that return HTTP 400 to a plaintext probe continue to be reported as HTTPS.
  • Cleartext HTTP 400 targets do not incur an unbounded or full normal probe-timeout delay from the HTTPS upgrade attempt.
  • Tests cover both successful TLS upgrade and unsuccessful HTTPS upgrade behavior.

Requested by @dwisiswant0.

Backlinks:

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

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